Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We recently migrated an ASP.NET website from Windows 2003 to Windows 2008 R2, by zipping up all the files and extracting them to the new site.

Since migrating the web application is still able to upload and delete files (that are new), however, it's unable to delete files that were copied from the original Win 2k3 app.

We're guessing it's a permissions problem because the error is:

Access to the path 'E:.......PATH.....' is denied.

We've been trying to match the permissions of a newly uploaded file to that of a migrated files. Newly uploaded files seem to get the APP POOL user as a permission and the OWNER. However, the original files didn't have this.

Any help that anyone can be would be fantastic.


share|improve this question

I suspect the files you're trying to delet are also created by the application.

I that case, the permissions of the CREATOR OWNER principal determine the permissions of new files.

share|improve this answer
I tried changing the Owner of the old files to the applications App Pool user. Is that what you are referring to? – Andrew Duncan Mar 20 '12 at 12:03
No, you were talking about permissions, not ownership. When you create a new file, the CREATOR OWNER permissions are applied to it, along with anything inherited from higher up. – adaptr Mar 20 '12 at 12:07
I added the CREATOR OWNER permission and the app pool permission to the file and it is now "deletable." Just need a good way of applying this permission to all the files/folder in this directory. – Andrew Duncan Mar 20 '12 at 13:35
I think you're confused about what "permission" means. Windows' MACL (Mandatory Access Control List) scheme involves three parties: an object, a principal, and a set of permissions. You cannot add "permissions" to an existing object by manipulating principals; instead, you can only alter permissions FOR a given principal. – adaptr Mar 20 '12 at 13:46

Well, there's nothing in any of the products you've mentioned that would do this directly.

How did you migrate the app?

If the file system permissions changed (likely), have you fixed the files and (importantly) folder permissions so that they're broadly compatible with the intent of the previous app?

And if it was copied via an archiving system of some sort - have you checked the Read Only attribute (not permission, attribute) for all the files isn't set?

ATTRIB /S will dump out all file attributes in all subfolders - look for any R s on the problem files.

Finally, you might find the user doing the upload/deletion is not the same as they were. Use Process Monitor from Sysinternals ( to watch a user perform an action you're interested in, and check the identity is as expected, and the permissions are appropriate. New App Pool and user identities (and identity types) are introduced with IIS 7.

share|improve this answer
The migration was pretty basic to be honest... I zipped the contents of the "files" directory moved the zip from server A to server B and then unzipped into the new location. I'm beginning to think this wasn't the best strategy... – Andrew Duncan Mar 20 '12 at 12:46
The process monitor confirmed that the issue is that access to the file was denied to the App pool user. It's now working (having added the app pool user to the files). Just need to think of a way to assign this new privilege to all the other files. ICACLS doesn't seem to recurse. – Andrew Duncan Mar 20 '12 at 13:33
Do it at the folder level, and select the option to reset permissions on all subfolders and files when prompted. – TristanK Mar 20 '12 at 21:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.