Guest Leslie Posted July 9, 2007 Posted July 9, 2007 Hi. I have a growing number of files in NTFS folder shares (W2K) that I want to protect from modification or deletion by a group of users (call them 'GroupA'). I thought I would be able to achieve this by applying the deny delete, delete sub-folders and files, append data, change permission and take ownership permissions to GroupA on the files in question. As 'deny' permission takes precedence over 'allow' I expected any rights GroupA inherited to modify the file would have been superceded by the 'deny' permissions. However, when I tested this I found GroupA users were still able to delete the files. (I didn't check whether they could modify them) Looking at a GroupA user's effective permissions on a test file I found the 'delete' permission was not ticked. How can I achieve the desired outcome? The GroupA users still need to be able to create, modify and delete files in the folder which have not been 'locked down'. What was wrong with my reasoning? Thanks.
Guest Leslie Posted July 12, 2007 Posted July 12, 2007 RE: prevent files being deleted or modified... Well, I finally solved my own problem: I didn't previously realise that the allow folder permission "delete sub-folders and files" overrode the deny file permission "delete". This is counter to the general rule that deny overrides allow. I can't imagine why Microsoft designed this exception. It's also a shame that Microsoft's effective permissions function did not show the users true permissions - I did already know this function wasn't to be trusted though.... "Leslie" wrote: > Hi. I have a growing number of files in NTFS folder shares (W2K) that I want > to protect from modification or deletion by a group of users (call them > 'GroupA'). I thought I would be able to achieve this by applying the deny > delete, delete sub-folders and files, append data, change permission and take > ownership permissions to GroupA on the files in question. As 'deny' > permission takes precedence over 'allow' I expected any rights GroupA > inherited to modify the file would have been superceded by the 'deny' > permissions. However, when I tested this I found GroupA users were still able > to delete the files. (I didn't check whether they could modify them) > > Looking at a GroupA user's effective permissions on a test file I found the > 'delete' permission was not ticked. > > How can I achieve the desired outcome? The GroupA users still need to be > able to create, modify and delete files in the folder which have not been > 'locked down'. > What was wrong with my reasoning? > > Thanks.
Recommended Posts