Hello guys,

I wrote a script for setting up permission on fileserver resources.

icacls \\server\Client1 /grant "Browsing Group":(S,RD,X,RA,REA,R)

icacls \\server\Client1\Supervisor /grant "Special Permission This folder only Group":(X,RD,RA,REA,WD,AD,WA,WEA,DC,RC)

icacls \\server\Client1\Supervisor /grant "Special Permission Subfolder and files Group":(OI)(CI)(IO)(M,DC)

So browsing rights working fine... But the user cant see the folder Supervisor...(I see the applied perissions on the ACL on folder Supervisor)

If I add a  custom group/user by hand to the ACL on Supervisor the user are able to see the folder and also have the needed permissions.

I can also uncheck one special perission from a applied group, add it again and click on OK... then the user are able to see the folder and also have the needed permissions.

Thank you in ad

Hi Tim,

Would you please tell us how many users have this issue?

I suggest you uncheck all the permissions on this folder manually, then use icacls command to test again.

If some other groups contain some specific users, and these groups are assigned Deny access permissions, then these users cannot access the file. Thats because Deny permissions precedence is higher than Allow, also, explicit permissions precedence is higher than inherited ones.

Therefore, please check other groups and the explicit permissions on this folder.

Here are some related links below:

How Permissions Work

http://technet.microsoft.com/en-us/library/cc783530(v=WS.10).aspx

How IT worksNTFS Permissions

http://technet.microsoft.com/en-us/magazine/2005.11.howitworksntfs.aspx

Best Regards,

Amy Wang

• Edited by Amy Wang_Microsoft contingent staff, Moderator Wednesday, November 27, 2013 8:50 AM

Hi,

thx for your reply. Its for all users. There is no Deny access permissions defined. I did this with groups or users and I get anytime the same result...

Hi Tim,

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

Best Regards,

Amy Wang

Hi,

Please help export the Supervisor folder's NTFS permission by use subinacl.exe tool.

1. Download the subinacl tool from below link
http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&DisplayLang=en

2. Run command Subinacl /file \\server\Client1\Supervisor and post the result here.

Thanks

I have not the 100% same but similar problem, manually set permissions behave different from those set with icacls although the advanced tab of permissions show the very same:

- set permissions manually, everything works fine (inheritance completely cut off)
- view permissions with icacls
- set the exact permissions viewed with icacls with an icacls command
- result looks absolutely the same in advanced permissions tab (both locally on 2008 R2 server)
- access does not work anymore and icacls view looks different

- difference with your example: I am dealing with DENY delete permissions on "this folder only", they are there in both cases but once they are listed one line more often with icacls /view when set automatically than when set manually, although the line tells the very same entry
-> result is folder can be opened with doubleclick in Windows 7 Explorer when set manually (as subfolders and files have modify permissions) without problems (the behavior we want), but cannot be opened when set with icacls

Although I have not found a solution yet maybe this helps the others investigating your case, too.
Regards,
Constanze

--> found an answer for my case: use /deny:(DE) instead of /deny:(D) as (D) would block necessary synchronization permissions for SMB2

• Edited by ConstanzePretzler Monday, December 09, 2013 12:43 PM

Hi Tim, 

Wondering if you have ever found a fix for this.  I've got exactly the same problem.  I create a folder tree, manually remove inheritance and the Users/Authenticated Users from the ACL on the top/root folder, then run a number of ICACLS commands to apply permissions throughout the tree.  The user gets access denied until I manually edit the ACL, at which point the permissions seem to apply.

If you got anywhere with your issue, I'd love to hear about it.

Thanks in advance, Kevin

• Edited by Kevin Saucier Tuesday, May 06, 2014 7:47 PM

For the benefit of anyone finding this later, I was able to solve my problem of the permissions not applying right away using the troubleshooting steps listed above.  I downloaded SubInACL and ran it against the directory after applying ICACLS permissions and saved the output to a file.  I then manually modified one setting, applied, then removed the change and applied again.  I then ran SubInACL against the directory again and saved the output to a new file.  I then used a comparison tool (www.scootersoftware.com) and compared the 2 files (I had to rearrange the output as it seems to be random) and found 1 minor setting difference.

The difference was that, after manually making a change, one of the groups had a new right added to it - Synchronize.  You can't see the right in the UI, but you can apply it using the S identifier in ICACLS.  I wiped out my test folder, recreated it, and applied the ICACLS permissions again, this time including S.  I ran SubInACL one more time and saved the output to a new file and compared it to the file that I got after manually making the change and it was identical.  I tested access with my test user and I was successful.  

Looking up the Synchronize permission, I'm not sure why my change worked, but I don't care either.  I modified all of my other ICACLS statements (hundreds of them) to add the S and everything has been working just peachy since.  

Here's an example of one of my commands:

icacls "\\server\share\folder1\folder2" /grant:r "Domain\Group Name":(RX,WD,AD,DC,S) /L

Hope that helps someone!

• Marked as answer by Tim Buntrock Friday, May 09, 2014 9:26 AM

Hi Kevin,

thx man you made my day. Its working perfect with the "S".

I have this issue. A set of users direcorries with

1) admin has full rights

2) Specific user has grant read/write, but .....

3) The specific user has DENY for "delete".

Setting the permissions via the GUI works. Using icacls to produce the exact same permission fails for the user with with no access to the folder (admin has full access).

What I noticed that if you use the gui to look at permissions one of the use folders, tick a right, apply it and then remove that right the user has full access.

Even this works.

A folder is locked down to Admin and "Andrew". Andrew should have access to all but delete, but can not even access the folder! Use the GUI to add another user to the permissions. Give (say) "Paul" read access. Andrew suddenly has access to read and write but not delete (as should be the case). remove "Paul", and Andrew CONTINUES to work.