icacls silently adds SYNCHRONIZE to DENY ACL and Explorer sometimes asks for that permission

Richard Sharpe realrichardsharpe at gmail.com
Tue Apr 9 16:11:31 MDT 2013

On Tue, Apr 9, 2013 at 3:05 PM, Jeremy Allison <jra at samba.org> wrote:
> On Tue, Apr 09, 2013 at 02:16:09PM -0700, Richard Sharpe wrote:
>> Hi folks,
>> I am seeing a weird problem.
>> This problem came about because a customer is trying to use icacls to
>> set a DENY:(D,WDAC) entry on a folder. This succeeds, however, if they
>> access the folder with Windows Explorer while using SMB2, they get
>> ACCESS DENIED, but if they access the folder with Windows Explorer
>> while using SMB1 they do not get ACCESS DENIED.
>> the icacls command used was: icacls z:\some-dir /deny SOME-USER:(D,WDAC)
>> SYNCHRONIZE always gets added, but icacls refuses to show it.
>> The problem seems to be that icacls silently adds SYNCHRONIZE along
>> with DELETE and WDAC to the DENY entry. Over SMB2, explorer asks for
>> permissions of 0x00100081 while over SMB1 it only asks for 0x00000081.
>> The above is against Samba 3.6.12+. However, even with Win7 accessing
>> W2K08R2 via SMB where I have added a deny entry as above, I get ACCESS
>> DENIED. I will check SMB1 soon.
>> The icacls command used on the W2K08R2 system was: icacls test_dir
>> /deny SOME-USER:(D,WDAC)
>> Has anyone seen this issue before? The only way to avoid getting the
>> SYNCHRONIZE bit set is to use SDDL it seems (or smbcacls :-)
> Should we ignore the SYNCHRONIZE bit on access requests ?

I don't think so. There is a report out there from Microsoft that
icacls is broken in this regard:


> Let me have a look at the MS-FSA...

I am testing now to see if W2K08, when accessed via SMB1 gives the
same behavior.

If so, then I think we should do what Windows does. Especially since a
combination of PowerShell scripting and SDDL will do what the customer
wants to do, I believe (PS Scripting to get the SID for a user.)

Richard Sharpe

More information about the samba-technical mailing list