Through a process of trial and error, I have found that by NOT granting 'Write Attributes', this has the effect of preventing a user from modifying/deleting existing files (which is what I want). However, I would really like an explanation as to precisely why this works.
This is a function of precisely how a file modification occurs. When you modify a file, the operating system doesn't actually modify the file you're editing. It replaces the file you're editing with the copy you changed. So, essentially, a file modification takes a copy of the original file, loads it into memory (where you modify it), deletes the original file, and creates a new file with the same name in the same place. This is why NTFS Delete
permissions are required to modify files - in fact, if you check the Advanced permissions
on an NTFS object, there is no Modify
permission - a modification is really just a delete and a write.
So, in order to create that new copy of a file, it has to write the file attributes of this new file... and, of course, writing attributes requires the Write attributes
NTFS permission. So that is why you can't modify a file without having the Write attributes
NTFS permission.
Specifically, thanks to a chat with Fitzroy, the NTFS file attribute that needs to be written under the user's security context (that can't be, without the Write Attributes
permission), when modifying a file, but not when creating a completely new one, would be the file's LastModificationTime
. This is a part of the Standard Information
attribute, according to one of the Microsoft Core Team developers.
I am trying to prevent users from accidentally deleting a certain
folder in a parent folder, while still giving them modify permission
on all other files and folders in the parent folder. But they should
be also able to modify files and folders in this certain folder
Prevent Folder Deletion or inadvertent Drag and Drop with NTFS security
If you want to prevent a specific folder from being deleted or dragged and dropped elsewhere, even if it has elevated implicit permissions, you can set an explicit DENY
to the FOLDER ONLY
for the user account or security group which you want to prevent this action from being performed.
You can complete this folder security lock down using ICACLS with a local path (e.g C:\Path\FolderA\FolderE
) or a UNC path (e.g \\server\share\FolderA\FolderE
).
Example ICACLS syntax to run from an elevated command prompt
ICACLS "\\server\share\FolderA\FolderE" /deny "<UserOrGroupNameToDeny>":(DE)
Permissions Used
/deny user:permission
Explicitly deny the specified user access rights.
This will also remove any explicit grant of the
same permissions to the same user.
perm is a permission mask and can be specified in one of two forms:
a comma-separated list in parentheses of specific rights:
DE - delete
What this does
Running the above with those options in that syntax will set an explicit DENY
to the NTFS DELETE
permission on that FOLDER ONLY
to that specific user account of security group.
You can confirm the deny permissions to the folder for the user account or security group by:
right-click
the folder you've used in the command,
- Select the Security tab,
- In the
Group or user name:
area scroll to or select and highlight
the account or group you've used in the command,
- In the
Permissions for Administrators
area you will see the NTFS permission attributes for Allow
and Deny
- You'll see a check mark in the
DENY
column of the special permissions
row for the account or group you've used in the command
- Select Advanced and go to the Permissions tab
- Check for the
Name
(or Principal
) value that you used in command, for DENY
in the Type
field
- The
Permissions
(or Access
) field should show Delete
and the Apply to
(or Applies to
) will show this folder only
NOTES
Please note that unchecking an ALLOW DELETE attribute is not the same as leaving that in place as-is and then creating a separate NTFS ACL rule for this same security group or user account saying to explicitly DENY the DELETE security.
This solution does NOT disallow DELETE this way
(WRONG)
This solution WILL explicitly DENY DELETE at this level to THIS FOLDER ONLY
(CORRECT)
(CORRECT)
Further Reading and Resources
Best Answer
On the folder (important: set the Applies to for the access rule to This folder only), make sure the user only has these permissions:
(If you're setting a deny entry, block these: Create files, Create folders, Write attributes, Write extended attributes, Delete subfolders and files, Delete, Change permissions, Take ownership.) On the file, deny these permissions for the user:
That arrangement produces the desired results for me on Windows 10. You can use the Effective Access tab of the folder and file to make sure that you don't have other rules interfering with these.
The user will then be able to read and write that file. The user will be unable to rename the file, create new files in that folder, or delete that file. Note that if the user has the "delete" permission on other files in that folder, it will be able to delete them.
Note, of course, that since the user can write to the file, it could just delete everything in it without deleting the file itself. If you don't trust this user, keep backups.
For Excel files specifically, this doesn't do the whole job. Office programs always save the document to a temporary file, delete the original, then rename the temporary one to the real one. You can kind of get around this by fiddling the Registry as instructed by this Microsoft article. Open this key in the user's account:
For Office 2013, change
14.0
to15.0
. (It's16.0
for Office 2016.) Create a new DWORD value calledEnableSimpleCopyForSaveToUNC
with the data of1
. You'll also have to change the permissions on the folder to let the user Create files / write data. (But since it's on the folder only, the user won't be able to mess with anything else in it, only create new files.) That will let the user save the Excel document, but sadly, the temporary file will stick around.Would-be commenters might think that
CREATOR OWNER
permissions, hardlinks, or network shares might help with that, but no.