ACL Error 0x56F: No Inheritable Components in Windows

When This Error Hits

You're setting up permissions on a shared folder—maybe a project directory on a Windows Server 2019 box. You copy an ACL from another folder using something like icacls.exe \\source\folder /save acl.txt then apply it with icacls \\target\folder /restore acl.txt. Or you use a script that grabs a security descriptor and sets it on a new folder. Suddenly, you get the error: ERROR_NO_INHERITANCE (0x0000056F). Windows tells you the ACL has no inheritable components. The folder doesn't propagate permissions to subfolders—new files and subdirectories inherit nothing, breaking access.

Root Cause

The problem is simple: the ACL you applied contains only explicit ACEs (access control entries) with no inheritance flags set. Every ACE in the ACL has its inheritance flags set to zero—no CONTAINER_INHERIT_ACE or OBJECT_INHERIT_ACE. This usually happens when you export an ACL from a file (not a folder) or from a folder where someone manually removed inheritance from all ACEs. Windows expects that an ACL applied to a folder will have at least one inheritable ACE for sub-objects. When it doesn't, the API call fails with 0x56F.

How to Fix It

Step 1: Check the current ACL

Open PowerShell as admin and run:

Get-Acl -Path "C:\TargetFolder" | Format-List

Look at the Access property. Each ACE shows something like IsInherited: False and InheritanceFlags: None. That's the problem.

Step 2: Reset inheritance on the folder

You need to force the folder to inherit from its parent first. Run:

icacls "C:\TargetFolder" /reset /t /c

/reset replaces the ACL with the default inherited permissions from the parent. /t applies to subfolders, /c continues on errors. This clears the bad ACL and gives the folder proper inheritable permissions.

Step 3: Apply your custom permissions with inheritance flags

Now set the permissions you actually want—but include the inheritance flags. For example, to give Domain Users read/write access that inherits to subfolders and files:

icacls "C:\TargetFolder" /grant "Domain Users:(OI)(CI)M" /t

(OI) means object inherit (files), (CI) means container inherit (subfolders). M is modify access. Without (OI) and (CI), you get the same 0x56F error.

Step 4: Verify inheritance flags

Check the ACL again:

Get-Acl -Path "C:\TargetFolder" | Format-List

Look for InheritanceFlags: ContainerInherit, ObjectInherit. If it says None, you missed the flags. Re-run with the correct (OI)(CI).

If It Still Fails

Three things to check:

1. Parent folder inheritance might be blocked. If the parent folder has inheritance disabled, /reset may not work. Enable inheritance on the parent: right-click parent > Properties > Security > Advanced > Enable inheritance.
2. You're using a raw security descriptor. If you imported an SDDL string from a file, the descriptor might lack inheritance flags. Open the SDDL and ensure OI and CI appear in the ACE strings (e.g., D:ARAI(A;OI;FA;;;SY)).
3. Powershell Set-Acl approach. If you used Set-Acl with an ACL object that had no inheritable rules, rebuild the ACL with proper flags:

$path = "C:\TargetFolder"
$acl = Get-Acl -Path $path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("Domain Users","Modify","ContainerInherit,ObjectInherit","None","Allow")
$acl.AddAccessRule($rule)
Set-Acl -Path $path -AclObject $acl

This creates a rule with inheritance flags set explicitly. Then test with Get-Acl again. If the error still pops up, your security descriptor was malformed—start fresh with icacls /reset and rebuild from there.