File System ACL Corruption Detected? Here's the Fix

What's ACL Corruption and Why Should You Care?

ACL stands for Access Control List — it's the list of permissions on every file and folder telling Windows who can read, write, or delete. When that list gets corrupted, you'll see errors like "Access Denied" even when you're an admin, or weird behavior where you can't open a file but your account owns it.

I've seen this on everything from Windows 10 workstations to Server 2019 file shares. The culprit is almost always a sudden power loss, a failing hard drive, or a bad SATA cable. Sometimes it happens after a permissions change that didn't complete properly.

Here's the fix path. Do each step in order. Stop when the error goes away.

Step 1: The 30-Second Check — icacls on a Test File

Don't jump straight to chkdsk. First, let's see what we're dealing with. Open Command Prompt as Administrator (right-click Start, choose "Command Prompt (Admin)" or "Terminal (Admin)").

icacls "C:\Path\To\Your\ProblemFile.txt"

Replace the path with an actual file that's giving you trouble. You'll see output like:

BUILTIN\Administrators:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Users:(I)(RX)

If you see No information is available or the list is blank for a file that should have permissions — that's ACL corruption. If you see a bunch of SIDs (long numbers starting with S-1-) instead of usernames, that's also bad.

If the output looks normal but you still get errors, the problem might be something else (like a failing drive or a virus). Move to Step 2 only if the ACLs look obviously broken.

Step 2: The 5-Minute Fix — Reset Permissions with icacls /reset

This fixes most ACL corruption issues without a full chkdsk. Still in an admin command prompt, run:

icacls * /reset /t /c /q

What this does:

• /reset — replaces all ACLs with default inherited permissions
• /t — runs on all subfolders recursively
• /c — continues on errors (important, or it'll stop at the first bad ACL)
• /q — quiet mode, less noise

Run this from the root of the affected drive or folder. For example, if the problem is on your D drive, do:

d:
icacls * /reset /t /c /q

Warning: This will reset all custom permissions you've set. If you have carefully tailored permissions on network shares, don't run this blindly. But for a standard user drive, it's safe.

After this runs (might take a few minutes on a big drive), test if your error is gone. If yes, you're done. If no, move to Step 3.

Step 3: The 15+ Minute Fix — chkdsk with Repair

icacls /reset didn't work? Then the corruption is deeper — likely in the MFT (Master File Table) where ACLs are stored. chkdsk can fix that, but it takes longer.

Important: chkdsk takes the drive offline. You can't run it on your C drive without a reboot. Plan for downtime.

For a non-system drive (like D or E), run:

chkdsk D: /f /r /x

What each flag does:

• /f — fixes disk errors
• /r — locates bad sectors and recovers readable info (includes /f)
• /x — forces the volume to dismount first (so no open files interfere)

For the C drive, you'll get a prompt asking if you want to schedule it at next reboot. Say yes (Y) and restart your machine. chkdsk will run before Windows loads — this is normal. Let it finish. It can take 30 minutes to several hours on large drives.

After chkdsk completes, reboot again (it doesn't always require it, but do it anyway). Then try your file again.

If you still see ACL errors after chkdsk, the drive hardware might be failing. Check S.M.A.R.T. data with a tool like CrystalDiskInfo. A corrupt ACL is often the first sign of a dying drive. Back up your data now if you haven't.

Extra: When None of That Works

Rarely, I've seen ACL corruption caused by a buggy antivirus or backup software. Try disabling real-time protection in your AV temporarily, or check the backup software logs for errors during permission scans. Also check Event Viewer under System for disk errors at the time the corruption appeared.

Another corner case: on Windows Server with DFS-R (Distributed File System Replication), ACL corruption can happen if replication conflicts. In that case, check the DFS-R event logs and consider suspending replication until you fix the affected server.

That's it. Start with the simple test, move to reset, then to chkdsk. Most people fix it at Step 2. Good luck.