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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.