0

We have a web site that used to run on a Windows 2003 server with whatever version of IIS that had; I think IIS6. That site has been moved to a new server that's a Windows 7 server with IIS7. Since the move we have been getting errors on our site:

Access to the path 'someFile.ext' is denied.

The error occurs when the website is trying to delete files (the site has an upload feature and removes old files). Does anyone know what could be causing this?

Extra information:

  • When I remote desktop to the server and try to delete the files I get a windows prompt that says I need to provide administrator permissions to do so.
  • Some of the files may have been created by a user who's account has been disabled
  • The issues predate this change but the site was recently updated to an application pool that uses asp.net v4
  • If I go to the site and upload a file then I can remove that specific file without issue.
  • The server is vmware machine.
  • When I tried to upload a file with the same name as one that could not be deleted I got a 401 error.

If anyone has run into this issue before or knows of a way we can track down the cause of the issue I would be much appreciated.

William
  • 103
  • 2

2 Answers2

2

This is almost certainly a filesystem permissions issue, especially if you're not managing that server using Active Directory. When you copied the files over from the old server, the user that created them (its SID) is still technically the owner of them. Check NTFS permissions on the files and make sure that the user/account you use for IIS has delete permissions on them. To debug (remove this permission when you're done!), give "Everyone" full control on those files, and make sure they're owned by the local Administrator account on that server, or SYSTEM on that server.

The UAC prompt is also caused by not having permissions allocated correctly. It's prompting you to temporarily take ownership of, and change permissions on, a given file so that you can delete it.

Joel E Salas
  • 5,572
  • 16
  • 25
  • note that debugging this way (if its public) will open your server up to about a dozen or so script kiddie hacks. – Jim B Nov 29 '11 at 22:36
  • We haven't tracked down the issue for sure that I know of but these responses are helping our tech guy figure it out. Thanks. – William Nov 30 '11 at 22:54
1

My guess is you probably robocopied the files and set permissions manually. Sometimes this works most times it causes weird issues. I would suggest using webdeploy and re-migrate the website rather than copy files.

Another possible cause is an isapi filter with compatability issues.

EDIT:

If you choose not to repair the website, you can debug what permissions might be by using procmon to monitor fiel access and apply the appropriate permissions.

Jim B
  • 24,081
  • 4
  • 36
  • 60