Windows folder permission only to a user and deny all others of his group

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).

In NTFS permissions, Deny attributes overrule unset or Allow permissions. If the read-only group has write set to deny, no amount of allow rules from any other group membership will work.

There is an exception to this:

• Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry. (Source: Technet)

Also, and this may or may not apply to your set up, Share permissions are also applied, and if a share's permissions aren't set to allow changes, the user still won't be able to write to the folder even with the correct NTFS permissions.