Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

migrated from Dec 7 '10 at 14:26

This question came from our site for professional and enthusiast programmers.

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

share|improve this answer
The other answer suggests that you could just do get-acl path_to_corrupt_file | set-acl -path ptah_to_corrupt_file. – binki Sep 19 '15 at 16:56
up vote 1 down vote accepted

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.

share|improve this answer
Thanks for the trick. I had the problem today and wrote a small powershell to automate the fixing : – Julien Roncaglia Oct 29 '14 at 12:39

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

share|improve this answer
  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
share|improve this answer
This solution is already mentioned in the question. However the author asks for an automatic solution. – scai Dec 9 '15 at 13:59
Also, these are NTFS permissions, so IIS isn't involved. – splattered bits Dec 9 '15 at 14:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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