Fix ACL corruption on NTFS drives after power loss

When does this happen?

You plug in an external USB drive, or reboot your desktop after an unexpected shutdown, and suddenly you get "Access Denied" on folders you accessed yesterday. The drive isn't dying — SMART still passes — but permissions are completely mangled. Some files show "Unable to set security information" errors. The event log might show NTFS or VolSnap warnings. This is classic ACL corruption, not a hardware failure.

What's actually happening here is that the NTFS transaction log flushed metadata for directory entries but the actual security descriptors didn't fully commit. The MFT (Master File Table) still references the old ACL pointers, but the data in those sectors is junk. So Windows sees an ACL that doesn't exist, and falls back to denying everything — including SYSTEM, in some cases.

Root cause — what broke?

NTFS doesn't write ACLs atomically with file data. They're stored in a separate area of the MFT called the $SECURE_DATA stream. When power cuts out mid-write, you end up with a dangling security descriptor index — the file's $SDS entry points to a corrupted or missing record. The filesystem doesn't detect this during a normal mount because NTFS doesn't verify every ACL on boot — it trusts the master table. That trust is broken here.

This is different from the "blue screen of death" driver bugs — it's a journal replay failure. The system tried to replay logged transactions but the ACL portion of the journal was truncated or had a checksum mismatch. So it gave up and left the drive in a consistent-by-metadata-only state. The data's fine, the structure's fine, the permissions are just garbage.

The fix — step by step

1. Mount the drive, but don't touch anything yet. If Windows throws a "you don't have permission" dialog, click Cancel. Do not take ownership via Properties — that can make things worse by forcing a partial ACL write on a broken descriptor.
2. Run chkdsk with the /f and /sdcleanup flags. Open an admin command prompt and run:

chkdsk E: /f /sdcleanup

The /sdcleanup flag tells chkdsk to go through the $SECURE_DATA stream and fix dangling security descriptor references. Standard chkdsk without this flag only checks the MFT file records — it won't touch ACLs. The reason step 3 works is that chkdsk rebuilds the security descriptor index by scanning each file's $SII (Security ID Index) and cross-referencing it with the still-valid descriptors in $SDS. It's basically a garbage collection pass for permissions.

3. If chkdsk reports "security descriptor corrupted" or hangs, you've got deeper corruption. Run instead:

chkdsk E: /f

Then restart and run the full /sdcleanup pass again. Sometimes the journal replay needs to happen first to stabilize the MFT.

4. Reset permissions using icacls — but only on the root folder, not every file. After chkdsk finishes, the filesystem should be consistent, but the ACLs might still be empty for some files. Apply a blanket reset:

icacls E:\* /reset /t /q /c

The /reset flag replaces the current ACL with the default inherited permissions for each file. The /t makes it recursive. /c continues on errors — you'll still get some permission errors on system files, but ignore those. This command essentially rebuilds every ACL from scratch based on the parent folder's inheritance. If inheritance was also broken, you'll need to explicitly grant permissions first.

5. If files still show "Access Denied" after icacls, you need to take ownership recursively:

takeown /f E:\ /r /d y
icacls E:\ /grant Administrators:F /t /q /c

This forces ownership to the Administrators group (not individual user — trust me, use Administrators) and grants full control. After that, run the /reset command again from step 4. The reason step 3 works is that takeown writes a valid security descriptor for the root folder, then the icacls reset propagates that down.

What if it still fails?

If you've done all four steps and still get permission errors, the problem isn't ACL corruption — it's likely NTFS metadata corruption in the directory index itself. In that case:

• Copy the data manually using robocopy with the /B (backup mode) flag. This bypasses ACL enforcement entirely:

robocopy E:\ D:\Backup\ /E /COPYALL /B /R:3 /W:5

• If robocopy fails on some files, the actual MFT record for that file is damaged. Boot from a Linux live USB and use ntfsfix to rebuild the MFT bitmap:

ntfsfix -b -d /dev/sdX1

• Last resort: Format the drive and restore from backup. If you don't have a backup, your data is at risk — this is a wake-up call.

One more thing: never use third-party permission tools like SetACL or Subinacl on drives with suspected corruption — they can write garbage ACLs that even chkdsk can't fix. Stick with Microsoft's tools.