Fixing "This access control list is not in canonical form" errors from the command line

Question

On several of our developer workstations, we've been getting the dreaded "This access control list is not in canonical form and therefore cannot be modified." error when we try and set permissions on certain folders. We haven't been able to figure out what is corrupting these ACLs.

Right now, the only way I know to fix it is to right-click the corrupted folder/file, choose Properties and click the Security tab. Windows will then notice the corruption and offer to fix it. I don't like this because it is manual and requires the user to do some investigations to figure out what folder/file is corrupt.

Is there a script or program somewhere that will do this automatically? I see that icacls has a /verify parameter, but it just shows me that the ACLs on a file/folder are corrupted. It doesn't offer to fix anything.

Answer 1

I was finally able to figure an automated fix for this. When you call PowerShell's Set-Acl cmdlet, it will re-order the ACLs correctly:

$path = C:\Path\To\Item\With\Borked\ACL
$acl = Get-Acl $path
Set-Acl $path $acl

Of course, it could be a parent of the directory that is messed up, so you should do some traversing to find the culprit. Use icacls C:\Path\To\Item\With\Suspect\CL /verify to figure out if something needs repair.

In our environment, Cygwin is the likely culprit: when it creates directories, it likes to give POSIX-style permissions on them, instead of relying on Windows to manage file system security.

Answer 2

You could try to use a simple PowerShell script to override the currupt files acl with the acl of another file: get-acl path_to_file_with_known_good_acl | set-acl -path path_to_corrupt_file

Answer 3

For me there was double trouble: non-canonical ACL + erroneous rule declared for NULL SID (WTH?). I suggest it was caused by cygwin version of git.

Anyway, in my case reapplying of the same ACL did not make any sense:

> Set-Acl $f.FullName (Get-Acl $f.FullName)
> (Get-Acl $f.FullName).AreAccessRulesCanonical
False
> (Get-Acl $f.FullName).GetAccessRules($True, $False, [System.Security.Principal.NTAccount]) | ? {$_.Identityeference.Value -eq "NULL SID" }
FileSystemRights  : WriteExtendedAttributes, ExecuteFile, DeleteSubdirectoriesAndFiles, ReadPermissions
AccessControlType : Deny
IdentityReference : NULL SID
IsInherited       : False
InheritanceFlags  : None
PropagationFlags  : None

So I've had to explicitly apply ACL from file having correct one, as mentioned by @mschneider

Answer 4

icacls can fix it also:

c:\> accesschk -q FILE
Error: FILE has a non-canonical DACL:
   Explicit Deny after Explicit Allow

c:\> icacls FILE /t /q /c /reset
Successfully processed 1 files; Failed processing 0 files

c:\> accesschk -q FILE
.. OK

Other handy commands, equivalent of chmod 0777 FILE, chown root FILE

  icacls  FILE /t /q /c /grant    :r Everyone:F
  icacls  FILE /t /q /c /grant    :r Everyone:F /inheritance:r
  icacls  FILE /t /q /c /setowner Administrators

Answer 5

This problem appears when using Cygwin. It tries to emulate POSIX file permissions on top of Windows ACLs. This frequently leads to non-canonical ACLs, which are legal but cannot be dealt with properly by explorer.exe.

You can turn off this problematic emulation by mounting with the "noacl" Option, e.g. in /etc/fstab:

none /cygdrive cygdrive binary,noacl,posix=0,user 0 0

Answer 6

1. In IIS right-click the folder with the issue
2. Edit Permissions...
3. Select the Security tab
4. Click 'Edit' button and save (this seems to re-order the acl)
5. Confirm all Popup's