Fix STATUS_COMPRESSION_DISABLED (0XC0000426) on NTFS Volume

You're copying a file from an old backup drive, or running a disk-level backup tool like Veeam or even Windows Backup and Restore, and bam – error code 0xC0000426 pops up: "STATUS_COMPRESSION_DISABLED – Compression is disabled for this volume." Happened to a client last month with a 2016 server that had NTFS compression enabled on a data drive, then someone (thinking they were clever) turned it off via fsutil to "speed things up." Problem is, some files on that volume were already compressed. The OS won't touch those compressed files anymore because the volume-level flag says compression is off. This isn't about file-level compression settings – it's a volume-level flag that Windows checks before allowing any read/write to compressed data.

Root Cause

NTFS volumes have a hidden flag called COMPRESSION_DISABLED that you can toggle with fsutil. When it's set, the entire volume refuses to handle compressed data – even decompressing existing files. The OS sees the flag and says: "Nope, not gonna touch that." This flag is separate from the per-file compression attribute. So you can have a file with compressed attribute set, but if the volume flag is off, Windows errors out. Common trigger: someone runs fsutil behavior set disablecompression 1 (which disables it system-wide) or fsutil volume setcompressiondisabled C: 1 (per volume). Some backup software also trips this flag during restores if it tries to write compressed files to a volume that doesn't support it.

Fix: Enable Compression on the Volume

Open Command Prompt as Administrator. Right-click Start, choose "Command Prompt (Admin)" or "Terminal (Admin)".
Check current compression status. Run this command, replacing C: with your drive letter:
```
fsutil volume compressiondisabled C:
```
If it returns Compression disabled: 1, that's your problem. If it's 0, skip to the alternative fix below.
Re-enable compression. Run:
```
fsutil volume setcompressiondisabled C: 0
```
This clears the flag and lets the volume handle compressed files again. No reboot required – the change is immediate.
Test. Try your original operation again. If it's a file copy, just try copying one compressed file. Should work now.

Alternative Fix: Decompress Existing Files

If you can't re-enable compression (maybe security policy forbids it, or the volume is a system drive you don't want to mess with), you need to decompress all existing compressed files. This is slower but safe. Do this:

Find compressed files. Open File Explorer, navigate to the root of the volume, and in the search box type compressed:true. This lists all files with compressed attribute.
Decompress them. Use PowerShell or command line. I recommend PowerShell for bulk operations:
```
Get-ChildItem -Path C:\ -Recurse -File | Where-Object { $_.Attributes -match "Compressed" } | ForEach-Object { compact /u $_.FullName }
```
This decompresses every compressed file on C:. Be patient – could take hours on large drives.
Verify. Run the original backup or copy operation again. It should proceed without error because there are no compressed files left to trip the flag.

What If It Still Fails?

If neither option works, here are three things to check:

Check if the flag is set at the system level. Run fsutil behavior query disablecompression. If it returns 1, run fsutil behavior set disablecompression 0 to re-enable it system-wide.
Check for third-party software interference. Some backup tools (looking at you, old versions of Acronis) set this flag intentionally to prevent compression conflicts. Check your backup software settings for an option like "Disable NTFS compression on target volume" and turn it off.
Corrupt volume flag. Rare, but the flag can get stuck. Run chkdsk C: /f to fix volume-level corruption, then try the fsutil command again. Had a client whose flag wouldn't clear until after a chkdsk fixed a bad MFT entry.

This error is almost always a flag issue, not hardware failure. Don't waste time with disk tests or driver reinstalls. Fix the flag, move on.