0

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.

ACL for Server1\Users

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:

  1. 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?

  2. 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?

3
  • 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. Sep 14, 2018 at 19:41
  • 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". Sep 14, 2018 at 19:42
  • @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
    Sep 16, 2018 at 13:55

2 Answers 2

0

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

  • Permissions are inherited

    For example, if the Everyone group was granted Full Control to the Sales folder, then the Everyone group would have Full Control to a new document called FY08 in this folder. (page 287)

  • Permissions are cumulative

    As an example, imagine that you are a member of both the Sales group and the Marketing group. If the Sales group is granted Read permission to a folder and the Marketing group is granted Write permission to the same folder, then your effective permissions are Read and Write - the accumulated permissions from both groups. (page 287)

  • Deny takes precedence

    For example, if Joe was specifically denied Write permission on a folder named Sales, but Joe was a member of the Sales group that was granted Full Control to the folder, Joe would not be able to write to this folder. (page 287)

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.

1
  • 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!
    – nepdev
    Sep 14, 2018 at 19:33
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .