I'm having an issue with Windows 2012 R2 where setting NTFS permissions on the root of a share breaks inheritance, and the NTFS permissions are effectively replaced with the new ACE. The only way I can illustrate this is by showing how I've reproduced this issue.
First of all, let's take the Share out of the equation - where everything works just fine.
I've created a folder under C:\ called Data. If I get the current ACL, it all looks correct.
C:\>icacls c:\data
c:\data NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
BUILTIN\Users:(I)(CI)(AD)
BUILTIN\Users:(I)(CI)(WD)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
Now, I'm going to add an ACE - a very basic one.
C:\>icacls c:\data /grant everyone:(RX)
processed file: c:\data
Successfully processed 1 files; Failed processing 0 files
I can verify that this has worked, by re-running the first command.
C:\>icacls c:\data
c:\data Everyone:(RX)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
BUILTIN\Users:(I)(CI)(AD)
BUILTIN\Users:(I)(CI)(WD)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
No problem so far. I've now removed the ACE, and shared the C:\Data drive as Data, using the following command:
Net share Data=C:\Data /grant:Everyone,full
Checking the ACL of this share, I can see that they're the same as C:\Data - as they should be.
C:\>hostname
mgmt57
C:\>icacls \\mgmt57\data
\\mgmt57\data NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
BUILTIN\Users:(I)(CI)(AD)
BUILTIN\Users:(I)(CI)(WD)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
Again, I add the same ACE as the first one, but this time to the share.
C:\>icacls \\mgmt57\data /grant everyone:(RX)
processed file: \\mgmt57\data
Successfully processed 1 files; Failed processing 0 files
You will now see the problem, when I verify the ACL.
C:\>icacls \\mgmt57\data
\\mgmt57\data Everyone:(RX)
Successfully processed 1 files; Failed processing 0 files
The same problem is apparent on the local disk.
C:\>icacls c:\data
c:\data Everyone:(RX)
Successfully processed 1 files; Failed processing 0 files
The only way I can correct this ACL now is to check the highlighted box below.
Now, the question is - how can I use ICACLS on the root of a share without it damaging the ACL as I have illustrated here?
I can confirm that:
- It is not a problem with one server - I've reproduced this issue on many.
- It's a problem with both Datacenter and Standard edition - but I have not tried any other OS other than Windows 2012 R2.
- The servers are fully up-to-date with patches
- The problem does not occur if I add ACE to a subfolder under root (for example, if I set ACL of a \\server\share\folder), which means my current workaround is to set the ACL's to \\server\c$\data. NOTE: This workaround requires you to be an Administrator of the server in question, which is why it's not a solution. In my use case, the individuals setting the permissions are not Administrators but have sufficient permission via NTFS to add new ACE's
- The share permissions are not relevant to the problem
- the NTFS permissions used in my example above is also not relevant - the problem occurs with any NTFS permission added to the root of the share.
- Using a method other than ICACLS (for example, Powershell and Set-ACL) gives the same result
- Only inheritance is broken - other permissions which have been assigned to the root folder remain intact. For example, if I add two permissions, I will see them both, and all inherited permissions will disappear.
- The issue is not cosmetic only - if I add a group I'm not a member of to the share root, and then try to use Windows Explorer to browse the local equavalent, I get the following error:
Sorry for such a long drawn out question, but I wanted to show that I've put a lot of effort into isolating this problem. I've not been successful in finding others with the same issue.
