Link to home
Create AccountLog in
Avatar of JohnPaddock
JohnPaddock

asked on

Can't stop user from deleting a file

I can't seem to take away users rights to delete a file.
I have a network folder that has 'domain users' full rights.
I want to make it so 1 file in that folder cannot be deleted.
I've tried removing 'domain users' rights completely, yet they can still delete the file.
I've tried adding 'domain users' and selecting 'deny' for all rights, and a user can still delete the file.
I don't want to change permissions on the folder since I want users to be able to do anything in the folder, except for deleting this 1 file.
What am i missing. (sever16 and Windows10)
Avatar of arnold
arnold
Flag of United States of America image

Run icacls on the file within the share on the server where it is being shared.
Add a rule denying the delete right to domain users. A user that is not a member of the domain users group will be permitted to delete.

The delete deny right will supersede and be enforced no matter what additional groups the user is a member of and what rights exist there.
Removing a right to delete from one group, does not deny a user who might be a member of another group where the delete right is still present.
Enable share auditing to record which users deletes the file.note this will add many entries into the security event log on the server.
Avatar of JohnPaddock
JohnPaddock

ASKER

Thanks, below is the icacls
It appears your sentence about the 'delete deny right will supersede' doesn't seem to be what I'm finding, although it is what I would expect to occur.
I enabled share auditing, but I'd still like to know why I can't deny users from deleting these files.  Maybe it's because they have full control of the folder that the file is in.  If anyone feels like experimenting in their own environment, I'd be curious if they find the same thing

icacls test.txt

test.txt MXX\Domain Users:(N)
         BUILTIN\Administrators:(F)

Successfully processed 1 files; Failed processing 0 files
An account that is not a member of the domain users group but is a member of domain admin's. Is permitted to delete the file.
Domain admin's, etc. are members of the built-in\administrators group.

Properties, security, advanced, effective, you can check which rights a specific user has.
Add deny delete right to the administrators group and see if that changes.

Try this, add e everyone group with only deny delete right.
ASKER CERTIFIED SOLUTION
Avatar of kevinhsieh
kevinhsieh
Flag of United States of America image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
the question is on restricting rights to a user on a file. Log off/logon unnecessary in these types of scenarios.
If a user has full control they can modify the ntfs permissions and delete the file.  if it is ONE file remove ownership and only allow READ.. explicit deny overrides the allow permission.
Thanks for the replies
Arnold, the user in question isn't a domain admin.
The effective rights show the user with all red X's.
I added the deny delete right ot admins, didn't help
Added everyone group with deny delete, didn't help

To HelloThere, users don't need to log off when applying permissions.  They do need to log off/on when changing group membership though, for that to affect permisions.

DavidJ, I tried that, but user is still able to delete the file.  It doesn't appear that explicit deny delete is over-riding anything.

Kevinhsieh, I set the file to read-only, and that seems to work, but doesn't make sense, but it does seem to work.  Thankyou.

I'd still like to understand why this doesn't work.  Could someone try this in your environment, just to see if it's the same everywhere?

Give everyone full control to a folder.
Put a file in the folder and deny everyone all access.
See if a regular user can still delete the file.  Maybe that's just the way windows works.
if the user has no rights on the file, the user would then not be able to delete the file. Something else is in play or you have another set of means by which users are provided access and that specific method does not use user rights but is preset.
If everyone group is set to deny delete, the deletion should not be permitted. when tried it should error out with message permission denied.

Just tested this on a windows 10 workstation. and the deny rule does not bar the deletion of the file.
create a new file, set permissions by adding everyone group with a deny delete rights.
this is not how it supposed to behave.

It is a bug.
SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
I've used on the directory level, but that bars all file modification not a granular as the person is looking for. It would seem the suggestion provided earlier to make the file read-only is the only remaining option. but a user with rights intent on deleting the file, could switch the read-only .....
No, users can't change the read-only attribute, it says access denied.  So setting it to read-only actually works.

I see that the folder permissions include 'delete subfolders and files'.  But I want users to be able to delete newly created subfolders and files, so I can't remove that, since then new files won't inherit that permission and won't be deletable.

Why would microsoft add that delete permission option to file security if it has no effect.  There must be more to this story.  

I was thinking this is a bug, but windows7 does the same thing.  I don't understand but at least we have solution.

Thanks for the help everyone
likely the display of available option is not dynamically checked to see whether the option applies
the display is the generic used for all objects within the file system.

note denying delete on the folder level will mean that no file can have their names changed if i recall correctly.
MS has a feedback hub that people could use to provide suggestions regarding this or any other issues you might have
https://t.co/u5o6skPtof?amp=1
ok great. thanks