On my Windows server I have a share called 'Data', inside data are 3 child folders called 1, 2 and 3.

The NTFS permissions are as follows

Data (The AllStaff group has Modify here, Admins have full control) -folder1 (inherits parent permissions) -folder2 (The AllStaff permissions have been removed and 2 non-admin users are added with Modify permission) -folder3 (inherits parent permissions)

My problem is that everyone can still read and write into folder2, eventhough looking at the NTFS permissions the folder is not inheriting perms from the parent and onlt 2 users should have access (plus admins), yet everyone can access it!

I decided to start over and leave the AllStaff group with Modify permissions on folder2 but check the 'Deny' box for each type of permission, I gave the 2 users Modify, now the 2 users that should have access can't get in, they are members of the AllStaff group so I can see why this would be.

Can someone explain why I can't achive my goal? Basically 2 users need a private folder within the Data share.

Many many thanks Scott

2 Answers 2


NTFS doesn't support blocking only certain inherited permission (which happens to be the only feature I'd like to see from the old Netware filesystem-- inherited rights filters). As such, you should design your permission hierarchies with an approach that grants the least permissions at the high levels, and adds permission at lower levels.

You're designing a permission hierarchy upside-down, basically.

I'd set the permission on the "data" share to something like:

  • Administrators - Full Control
  • SYSTEM - Full Control
  • Authenticated Users - List Folder Contents - This folder only (set in the "Advanced" dialog)

Then, I'd create sub-folders for each specific necessary use and grant permission to those folders to the groups who will need access.

This has the nice side-effect of keeping users from populating the root folder of the "data" share with their own files and directories. If you don't have a the "heap of files" problem yet and you do allow users to populate that root directory you will quickly be into such a mess. (We have Customers who have spent a lot of money, relatively speaking, cleaning up messy "public drives" because they didn't start with a good subfolder / permission strategy and allowed huge amounts of files to pile up for years. It's like quicksand-- you get stuck in it and, once users have spreadsheets with "links" into the "swamp", shortcuts to files in the "swamp", etc, you can't get out easily.)

Additionally, you shouldn't EVER name individual users in permissions except in cases of wholly user-specific directories (such as roaming profile folders, home directories, etc). All other permissions, even if they're for "just a couple people" should be based on groups. Turnover happens, and in the future when you need to give a replacement employee the "same rights" as the person they're replacing you'll be glad that you used groups. Instead of having to keep documentation about all the filesystem permissions you might've set (or, worse, having to grovel through it by hand) you can just put the new user into the same groups as the person being replaced and be assured that you've given the new wuser the the "same rights" as the replaced user.

The "Deny" permission in NTFS should set off alarm bells in your head. It's rarely used in well-designed permission hierarchies. Generally if you catch yourself needin to use "Deny" then you probably have designed things backwards.

Blocking permission inheritance should be avoided because it limits future permission flexibility. If you're going to do it, you should have a good reason.

Every time you break the inheritance hierarchy you limit your ability to add a permissions higher up in the hierarchy that, obviously, inherit down.

Suppose "the boss" comes to you and says: "I want the 'Executives' to have read access to the entire 'data' share". If you've blocked inheritance in 20 different places each one will need an ACL entry added. Compare that to adding a single ACL entry at the top of the hierarchy (assuming you never blocked inheritance anywhere in the hierarchy).

  • Another excellent, concise explanation. You should write a book! Feb 10, 2010 at 20:20
  • >smile< Thanks! I'll stick to Server Fault, though. I can't earn "rep" writing a book! (Danger-- mini-rant ahead. The whole idea of selling rights associated with "intellectual property" re: publishing a book makes me sick to my stomach. "Intellectual property" isn't property. I'll earn my money the honest way-- working with my hands and brain-- as opposed to trying to extract income from the same work (writing the book) over and over again (book sales).) Feb 10, 2010 at 20:57
  • Interesting point of view... I'd say that many of your answers clearly show that how something is written can add value to readily available information (standard documentation). It can be worth it to me and to a lot of other people to pay for that added value - a win-win situation. Anyway, this is all a tiny bit off-topic... Feb 11, 2010 at 4:15
  • @Ward: re: off-topic-- I'd agree. I've got views re: "intellectual property" that seem odd to the "mainstream". If the social contract that modern copyright law is based on could be renegotiated to be more fair for all the parties involved (i.e. works enter the public domain in a reasonable and limited amount of time, fair use rights re: "time shifting", transcoding, format-shifting backed-up by legal precedent, etc) I could get behind it. Until then I can't participate in that system w/ a clean conscience. (All my software development work is "work for hire", for example.) Feb 11, 2010 at 7:32

Denies will always over rule Allows. So if your 2 users are in the AllStaff group then they will be denied access.

As for your original problem, I understand the frustration, what you're decribing shouldn't be happening.

  • I thought so! Darn!
    – Scottio
    Feb 10, 2010 at 16:52
  • Actually, explicit allows take priority over inherited denies.
    – Doormatt
    Jan 20, 2012 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy