I know this has been asked but every answer I have tried over the past three hours has not worked. So I'm hoping to get a solution that works on my machine (running Windows 7).
Assuming following set up
Parent
File1
File2
SubFolder
I would like to set the permissions on Parent so that it cannot be deleted/moved/renamed but the subfolders and files (e.g. "File1"; "File2"; "SubFolder") all retain permission to be deleted/modified in anyway.
What I have done. Right click "Parent" > Properties > Security Tab > Advanced > Change Permissions > Deselect "Include inheritable permissions from this object's parent" and then select "Add" in the dialog that appears > Select "Administrators" > Edit > Apply to: "This folder only" > Check Deny for "Delete"
I then apply everything. However, I am still able to delete the folder.
Any help is much appreciated. Happy to supply screenshots or any additional information needed
Update
Attached are screenshots of my current settings. However, I still can click the folder and then hit the delete button on my keyboard and the folder will delete. I tried both with and without the explicit deny permission for delete and both times with the following settings was able to delete the folder as the logged in user.
Set Owner to SYSTEM
Permission Entries
User Permissions for the Folder
User Permissions for Subfolders
System Permissions
Explicit Deny Delete Permission for User (Tried with and without)
Best Answer
As a rule of thumb, you should avoid explicit DENY rules in ACLs. If one is required, it is often because the data is already structured wrong.
The ability to delete or rename a folder is not decided by the
Delete
permissions on the folder in question, but by theDelete subfolders and files
permission on the parent folder. This is counter-intuitive and different from how permissions for a file work. It definitely doesn't work as you would expect.Let's use the following folder / file structure as an example:
FolderB
andFile1
are in parentFolderA
.FolderC
andFile2
are in parentFolderB
and so on.Now, if we remove the
Delete
permission fromFile1
,File2
, orFile3
, for any user, that user will be prevented from renaming and deleting the file. This is also true if you use an explicit DENYDelete
on the file.However, if you remove the
Delete
permission fromFolderA
,FolderB
, orFolderC
, for any user, that user will still be able to rename and delete the folder. This is also true if you use an explicit DENYDelete
on the folder.Why is that? Because the
Delete
permission is a permission that applies to files, not folders. Instead, we must remove theDelete subfolders and files
permission from the parent folder to accomplish what you are asking.In our above example, we will need to remove the
Delete subfolders and files
permission from FolderA, for a particular user, assigning the permission tothis folder only
. In that case, the user will then be unable to modifyFolderB
andFile1.
The same is true if you use an explicit DENYDelete subfolders and files
onFolderA
instead.The user can still rename and delete
FolderA
unless the parent ofFolderA
has also restricted that permission. As long as you applied the permission tothis folder only
then the user will continue to be able to read/write/modifyFile2
,FolderC
andFile3
.The obvious drawback here is that it takes 2 levels of folders to accomplish what you are asking. In your case, you mention that you are trying to protect a Dropbox folder. So, your folder structure would have to look like this:
You would remove, for a particular user or group, the
Delete subfolders and files
permission forthis folder only
on theDropbox
folder. You would then add or maintain, for a particular user or group,Full Control
orModify
permissions forsubfolders and files
on theDropbox
folder.Now the affected user will be unable to modify any files or folders immediately below the
Dropbox
folder, but will be able to modify all files and folders contained in any subfolders.There is an additional concern here with Dropbox, because this is not a normal folder. The Dropbox application expects full control of the
Dropbox
folder. Being that Dropbox often runs as the logged on user, you can't prevent the logged on user from having full control of theDropbox
folder. You can try it, but the results may be unpredictable and chaos is likely to ensue.