STATUS_BAD_INHERITANCE_ACL (0XC000007D) Fix Guide

Cause #1: Corrupted Inherited ACL on a Folder or File

This is the most common trigger. You'll see it when you try to copy, move, or delete a file, and Explorer throws the error. The culprit here is almost always a corrupted security descriptor — Windows can't read the inheritance flags properly. I've seen this on Windows 10 Pro 22H2 and Server 2019 after a botched backup restore or a third-party antivirus scan that messed with permissions.

Real-world scenario: A user tries to move a PDF from a shared drive to their desktop. The error pops up, and the file stays put.

Fix: Reset permissions with icacls

Open an elevated Command Prompt (right-click CMD, Run as Administrator). Then run:

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

The /reset flag replaces all ACLs with the inherited default from the parent folder. /t does it for subfolders, /c continues on errors, /q keeps it quiet. If the path has spaces, wrap it in quotes.

If that doesn't work, force inheritance off and on again:

icacls "C:\Full\Path\To\FileOrFolder" /inheritance:d

Then re-enable it:

icacls "C:\Full\Path\To\FileOrFolder" /inheritance:e

This flips the inheritance flag, which often clears the corruption. Test the file operation again.

Cause #2: Group Policy Inheritance Conflict

Sometimes the error comes from a domain-joined machine where Group Policy sets explicit deny permissions on a parent folder. When a child object inherits those, Windows can't build the ACL correctly. I've seen this on Windows 11 with Office 365 files synced through OneDrive — the policy blocks inheritance, but the file still tries to inherit.

Real-world scenario: A user can't open a .docx from a mapped network drive. The error appears instantly.

Fix: Check and clear explicit deny entries

Run this command to see the current ACLs:

icacls "C:\Path\To\File"

Look for lines starting with (DENY). If you see them, you need to remove them. But don't remove deny rules from system folders — only from user data. Use:

icacls "C:\Path\To\File" /remove:g "BUILTIN\Users"

Replace Users with the specific group showing the deny. Then reapply inheritance:

icacls "C:\Path\To\File" /inheritance:e

For domain machines, also check local Group Policy (gpedit.msc) under Computer Configuration > Windows Settings > Security Settings > File System. If there's a policy targeting that folder, remove it and run gpupdate /force.

Cause #3: Filesystem Corruption or Drive Errors

Less common, but I've seen it. If the NTFS Master File Table (MFT) has a bad entry for the file's ACL, Windows can't read the inheritance chain. This usually happens on USB drives or older hard drives that were yanked out mid-write. Or after a sudden power loss on a server.

Real-world scenario: A user plugs in an external drive, copies files, then the error shows on a few random files. Everything else copies fine.

Fix: Run chkdsk

Open an elevated Command Prompt and run:

chkdsk C: /f /r

For external drives, replace C: with the drive letter. The /f fixes errors, /r recovers bad sectors. Expect it to take a while if the drive is large or has lots of errors. Reboot if it asks — it'll run at boot time.

After chkdsk finishes, try the icacls reset from Cause #1 again. Sometimes chkdsk fixes the MFT but the ACL stays corrupt.

Quick-Reference Summary Table

If none of these work, try booting into Safe Mode and running the icacls commands again. Some third-party shell extensions (like Dropbox or Google Drive) lock files and cause this error. Disable them one by one to find the culprit.