0

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.

Advanced Security Settings for data

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:

You don't currently have permission to access this folder

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.

1 Answer 1

0

This is by design. If you attempt to set the permission using Windows Explorer, you will see the following message:

Windows Security

Workarounds are your only solution.

You must log in to answer this question.

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