Shared Windows Folders - Subfolder Permission Issue

Question

Windows Server (any version), shared folder with subfolders, something like this:

 Department1
     Jim
     John

where Department1 is the network share, and Jim / John are subfolders.

What I want is that only Jim has write-access to the "Jim" folder (i.e. only Jim can create files and folders in the Jim subfolder), and only John has write access to the "John" folder.

Sounds easy, but I cannot find a way to do that.

Here is how the permissions are set:

 Folder "Department1"
    share permissions: Everyone - Change + Read
    NTFS permissions:  Jim - List Folder Contents
                       John - List Folder Contents

 Subfolder "Jim"
    NTFS permissions: Jim - Full Control

 Subfolder "John"
    NTFS permissions: John - Full Control

What happens is:

• In the parent shared folder "Department1", both Jim and John can CREATE, EDIT, MODIFY and READ any file and folder.
• Jim can CREATE, EDIT, MODIFY and READ any file and folder in his own and also John's folder
• John can CREATE, EDIT, MODIFY and READ any file and folder in his own and also Jim's folder

(I see this outcome both from the "effective permissions" tool and also when simply logging in as Jim and trying it out).

What SHOULD happen is - nobody can create files in the parent folder, and Jim should not be able to create/modify files in John's folder + vice versa.

If I take out the "List Folder Content" permission from the parent folder, neither Jim nor John can even access the share. But - the issue is: merely adding that LIST FOLDER permission seems to give both users the rights to create, read and modify files and folders ...? How can this be correct or logical?

It does not seem inheritance has anything to do with it - usually you can see inherited users and properties showing up in subfolders and they would be greyed out as they cannot be changed - that is NOT the case. (Inheritance is enabled.)

Sharing Jim and John as separate shares would handle it but I do not want this - the example is simplified, really there are hundreds, it would result in a "flat" non-hierarchical view from the network which I must avoid.

Adding DENY entries for all the "other" users which aren't meant to access the folder will be extremely unwieldy - there are hundreds.

So my questions:

1. Why does this happen? It is not logical - as soon as I give NTFS access to list folder contents, that user can also read, write, modify files and folders - is that supposed to be that way?

2. Is there a simple way to configure this so it works as intended? I am thinking along the way of turning off inheritance - but I want that any subfolder of Jim which he creates himself does inherit the permissions of the Jim folder, would that happen, even if inheritance is turned off on the share?

Edit

Accessing folders in above example is assumed to always occur from a client computer across the network to the file share. (I am aware that the scenario is different if Jim / John would log into the file server locally, but that is not my question.)

Update

Based on the comment from Evan Anderson I checked all permissions and found an entry inherited from Security permissions of the disk drive itself. It is a "special permission" entry for "server\users", which I understand means local users of that server. And that entry gives Create Files and Create Folders access, and is inherited to my Department1 and Jim/John folders.

I DID NOT CREATE THAT ENTRY. It seems to be a default entry created by Windows on every disk drive on every server I looked at.

Removing that entry changes the effective permissions for Jim and John both on the Department1 folder and on the subfolders so that the erroneous CreateFolder and CreateFile permission no longer applies - which is what I wanted. So thanks to Evan Anderson.

This opens two new questions though:

3. What do the server\Users entries apply to? My understanding seems wrong that this only applies to local users of the server. Jim and John are domain logins and do not exist as local users on the server. So is it correct that Server\Users applies to any and all users of the server, no matter whether logged in from the network or existing as local users on the server?

4. It seems that every disk drive has this special permission entry which then inherits to all folders on that drive - what is the purpose of having every drive with a default entry of CreateFile and CreateFolders for the server\users group? That sounds to me like a huge invisible trap for everyone trying to set proper permissions on Windows shares. (If true, any tutorial should really begin with the mandate "remove the Server\Users permissions entry from your disk drive".)

Update 2

I found the following datum regarding the Server\Users group at MSDN

"When a computer joins a domain, the Domain Users group is added to the Users group on the computer."

This means that Jim and John are part of the Server\Users group and that's why these permissions apply. So I answered question 3, but question 4 still remains - there should be some sense behind it?

Solution

Thanks to the comment from Evan Anderson I checked all permissions and found an entry inherited from Security permissions of the disk drive itself.

It is a "special permission" entry for "server\users". That entry gives Create Files and Create Folders access, and is inherited to my Department1 and Jim/John folders.

This seems to be a default entry created by Windows on every disk drive on every server I looked at.

On Microsoft domains, the DomainUser group is automatically added to the Server\User group so that any domain user has read + write access via NTFS permissions - so therefore, if I give share permissions to all domain users to access the share, this results in every user having read+write access to all folders on the share.

This default entry exists on all version of Windows server, and it makes it easy to add / edit folders on the server, when you are logged in locally.

However, it creates the above problem. I would have to set specific share permissions for the specific users, but obviously that won't work for subfolders.

Removing that server\user entry reveals what I believe is the reason why Microsoft keeps this entry still today in their default ACLs - in that moment only the administrator group has access to the folder, and this means every edit, every access (locally on the server) brings a UAC popup, which is very annoying.

(On Server 2016, after having removed the server\user entry, it does ask you whether you want to add your user name to get control to all folders permanently. That is a nice workaround - it just adds that single user to the ACLs which then does not bring

I recommend also to follow the very good answer from Evan Andersson here which he references in his comment and gives very good tips for setting up folder hierarchies.

Comments

[Spence]

Post screenshots of the share and NTFS ACLs, please. Jim and John can't be able to create or modify files in the "Department1" folder the way you've illustrated the example. You've got more entries in you ACLs than you're illustrating here.

[Spence]

You might also look at my answer here, too: serverfault.com/a/111643 It talks about setting up a "data" share with a very small ACL that won't have any "side effects".

[nepdev]

@Evan Anderson - thanks and see my update above. Factually there seems to be a default entry created by Windows on the Server\Users group - the entry is on the disk drive itself and inherited on every folder of the drive! And it gives CreateFile and CreateFolder access!

[nepdev]

Thanks for your explanation, and a good point on the cumulative effect of permissions. With "logging in" I always meant across the network - sorry for not being clear. I don't seem to quite get it yet though. In my example, in the parent folder "Department1" has only one permission set which is "List Content" for both Jim + John. So why can Jim create and modify files in that parent folder? That was my question - the cumulative permission for NTFS is "List Content", the cumulative for Sharing is "Change+Read". What wins is Change+Read - not the most restrictive!