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

Posted on

A server stack is the collection of software that forms the operational infrastructure on a given machine. In a computing context, a stack is an ordered pile. A server stack is one type of solution stack — an ordered selection of software that makes it possible to complete a particular task. Like in this post about Fixing “This access control list is not in canonical form” errors from the command line was one problem in server stack that need for a solution. Below are some tips in manage your windows server when you find problem about windows, access-control-list, , , .

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.

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:PathToItemWithBorkedACL
$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:PathToItemWithSuspectCL /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.

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

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
> (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

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

Leave a Reply

Your email address will not be published.