I am trying to prevent users from accidentally deleting certain folders (such as their personal scan destination folder - stored in their home drive), while still giving them read+write permissions to the contents of these special folders.
My experimentation with various different NTFS permission combinations has been unsuccessful, as I find that the users are either unable to access the contents... or able to delete the parent folder.
How can I do this?
As Graham pointed out, using multiple permissions entries for the same user (something I had never tried before) was the key here:
The permissions on the parent folder give the users almost absolute freedom to make any change... except that the "delete" box is unchecked - so users cannot delete/move/rename this important folder by accident:
Moving on to the second permission set for the same user (which apply not to the folder itself, but to its contents), we see the exact same rights granted to the user, including "delete" privileges.
So, users can do anything they wish to the subfolders and files, including deleting/moving/renaming them.
This configuration allows me to protect key folders, such as personalised target scan directories which reside in user personal network locations. Users can modify the contents (such as deleting PDFs of scans they no longer wish to keep), but cannot inadvertently cause problems for themselves by deleting a folder the scanner expects to see when saving to the network.
I had to disable inheritance for the special folder as it was otherwise not possible to make changes to the user's permissions which varied from the root of the network share; however, all subfolders and objects do use inheritance in order to obtain their permissions from their parent folder.
Once I figured out exactly what needed to be done, this only took a couple of minutes to adjust for each user. I now have peace of mind that key network folders cannot accidentally get deleted by users.
The folder should have read permission, delete subfolders and files, create folders /append data, create files / write data, read attributes, list folder / read data, traverse folder / execute file and that's it. The contents should be full control. This combination should (assuming correct ownership of the files and correct user creation and administration) allow your users to have access through the folder to it's contents, without them being able to delete or modify the folder itself.
The ability to delete something from a folder is usually dependent upon the permissions assigned by the parent and not the folder itself (i.e. You can't say: "Don't delete me"). So this means you need to control the delete permission of the folder itself in the permissions of the parent of the folder.
For example:
A |-B | + a.html | + b.html | + c.html +-C + a.doc + b.docThe ability to delete "a.html" is controlled by "B" (or inherited from "A"). So if you want to stop being able to delete "B" then you need to set the permissions properly on "A". This gets rather annoying when you want to be able to delete "C" but not "B". Sometimes assigning the ownership of a folder (but not its contents) to a separate user is easier and more obvious.
If Austin Power's answer is not working for you here's two other options
Just create a sub-folder with one empty text file and take away access for them from the users you wish to protect.
How does it work?: Since the users can't delete the file in the sub-folder they also can't delete the sub-folder and the parent folder.
Caution!: If you try to delete the parent folder you will indeed fail but only after everything inside has been deleted (except of course the special folder/file).
Follow this procedure Prevent Folder Deletion or inadvertent Drag and Drop with NTFS security
Nicely done on the accepted answer.
The short description is that you need this pair of permissions (below is a rough approximation of Windows 10 GUI):
Type Principal Access Applies to
--------------------------------------------------------------------------
Allow ... Modify Subfolders and files only
Allow ... Read, write & execute This folder, subfolders and files
icacls)You can set these permissions from the command line or a script using the icacls command as follows:
icacls directoryname /grant "principal:(OI)(CI)(RX,W)" "principal:(OI)(CI)(IO)M"
Where:
Example:
icacls "C:\Program Files\App\Temp" "*S-1-5-32-545:(OI)(CI)(RX,W)" "*S-1-5-32-545:(OI)(CI)(IO)M"
This allows members of the local Users group (SID S-1-5-32-545 - you can use SIDs with icacls if you prefix with * character1) the ability to create/rename/delete files and directories in the C:\Program Files\App\Temp directory, but they won't be able to delete the C:\Program Files\App\Temp directory itself.
1Currently a list of well-known SIDs is available at https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers - but seeing as how Microsoft moves things, a search for "well-known SIDs" should get you there.
Flags (see https://superuser.com/a/322431/204415 for more details):
(OI) - "object inherit" - this ACE (access control entry) will be inherited by objects placed in this container(CI) - "container inherit" - this ACE will be inherited by subcontainers placed in this container(IO) - "inherit only" - this ACE will be inherited, but does not apply to this object itselfPermissions:
(RX,W) - Corresponds to "Read, write & execute" in the GUIM - Corresponds to "Modify" in the GUIThus:
(OI)(CI)(IO)M corresponds to "Modify" access for "Subfolders and files only" in the GUI(OI)(CI)(RX,W) corresponds to "Read, write & execute" access for "This folder, subfolders and files" in the GUI