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:
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?
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:
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?
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?
According to my MCITP Study Guide (Server 2008, so it's old-ish. Text and examples taken directly from that textbook, with all rights reserved by the author/publisher):
When combining NTFS and Share permissions, you must identify what the cummulative permissions are for both NTFS and Share permissions, then determine the more restrictive of the two.
It's also important to remember that Share permissions are only applied when accessing a share over the network. So, if you're logging into the file server as Jim, you'll be using the NTFS permissions exclusively (connecting without UNC naming).
One thing I would try is to apply the List Contents permission to the parent folder, in this case Department1 and set the respective owners of the subfolders to Full Control. That would make the NTFS+Share permissions List Contents, as that is the most restrictive. You could also try removing inheritance of permission from the subfolders.
I used to administer a setup like this at a previous employer, but for the life of me, I can't recall exactly how we solved it. But maybe the above is helpful to you. Explicitly denying all other users should certainly be avoidable.
See this also for a shorter explanation of NTFS and Share permissions.
EDIT: As an addendum, permissions inheritance is turned on by default. I would think that even if you disable inheritance for the individual user folders, subfolders (eg. Jim/Folder1) would inherit from their immediate parent. I can experiment with this and get back to you definitively, if you would like.
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.