Fix ERROR_BAD_INHERITANCE_ACL (0x0000053C) in Windows

Why you're seeing 0x0000053C

This error shows up when the security descriptor for a file or folder has an inherited ACE (Access Control Entry) that can't be built properly. Happens a lot after restoring from backup, moving files between drives, or applying a security template that went sideways. You'll spot it in Event Viewer under System logs, or as a popup when trying to copy a folder. I've seen it on Windows 10 22H2, Windows 11 23H2, and Server 2022.

The core issue: Windows expects inheritance flags to be clean, but something corrupted them. Let's fix it.

Fix 1: Reset inheritance via Properties (30 seconds)

Try the quickest thing first. This works about 40% of the time.

1. Right-click the file or folder showing the error, choose Properties.
2. Go to the Security tab, click Advanced.
3. Near the top, look for Enable inheritance or Disable inheritance. If inheritance is already disabled, click Enable inheritance. If it's enabled, click Disable inheritance and choose Convert inherited permissions into explicit permissions.
4. Then click Enable inheritance again – this rebuilds the ACL clean.
5. Click OK twice and test.

If that doesn't pop up the button – some locked-down systems hide it – skip to Fix 2.

Fix 2: Use icacls in Command Prompt (5 minutes)

This is my go-to. icacls is the Windows Swiss Army knife for permissions. Open Command Prompt as admin. You need the path to the problem file or folder.

icacls "C:\Full\Path\To\ProblemFolder" /reset /t /c /q

Breakdown: /reset replaces all ACLs with default inherited permissions. /t does it for every subfolder and file. /c keeps going even if it hits errors. /q keeps it quiet – no confirmations.

Then force inheritance to be re-evaluated:

icacls "C:\Full\Path\To\ProblemFolder" /inheritance:e /t /c /q

The /inheritance:e flag explicitly enables inheritance on the object and all children. This rebuilds the ACEs from the parent. I've used this after failed backups on Server 2019 – it's solid.

Fix 3: Take ownership and reset ACL with PowerShell (15+ minutes)

For stubborn cases – maybe the file is owned by TrustedInstaller or SYSTEM, and no admin can touch it. You need to take ownership first, then blast the ACL.

Run PowerShell as admin. Replace the path with yours.

$path = "C:\Full\Path\To\ProblemFolder"
takeown /f $path /r /d y
icacls $path /grant "Administrators:F" /t
icacls $path /reset /t /c /q
icacls $path /inheritance:e /t /c /q

takeown /r recurses into subfolders, /d y answers yes to any dialog. Then I grant Administrators full control – you can change that to BUILTIN\Administrators if your system is in a domain. Then reset and re-enable inheritance like before.

If the error's on a system file (like in C:\Windows), be careful. Taking ownership of core system files can break Windows updates. I'd only do this on user data or app folders.

When to give up and re-create

If none of the above work – and I've seen it happen on a corrupted NTFS volume – copy the files to a new folder and delete the old one. Use Robocopy to preserve permissions if you need them:

robocopy "C:\OldFolder" "C:\NewFolder" /E /COPYALL /DCOPY:DAT

/COPYALL copies all security info, timestamps, and attributes. Then delete the original folder. New folder gets clean inheritance from its parent.

Why this error happens

Inherited ACLs are stored as flags on each ACE. When Windows tries to build the effective ACL, it walks up the tree. If any ACE has a corrupt inheritance flag – wrong flag for the object type, or a self-relative security descriptor that's malformed – you get 0x0000053C. Common triggers: restoring from a backup made with a different Windows version (e.g., Server 2012 backup restored to Server 2022), or using third-party file sync tools that don't handle ACLs properly.

One more tip: always check Event Viewer after fixing. Look for source Kernel-General with event ID 12. That'll show you the exact file path if you're hunting blindly.