STATUS_FVE_FS_NOT_EXTENDED (0XC0210006) – BitLocker Won't Enable
BitLocker throws this when the NTFS volume doesn't fill the entire partition. Usually a leftover from shrinking or cloning a drive. Fix it by extending the filesystem.
What's Actually Happening Here
You try to enable BitLocker on a drive – maybe C:, maybe a secondary disk – and you get STATUS_FVE_FS_NOT_EXTENDED (0xC0210006). The error message is surprisingly accurate: the NTFS filesystem doesn't extend all the way to the end of the partition. What you're looking at is a gap between where the filesystem thinks the volume ends and where the partition actually ends.
This almost always happens after you shrink a partition, clone a smaller drive to a bigger one, or restore a system image onto a larger disk. The partition table says the volume is, say, 500 GB, but the NTFS metadata still thinks it's 256 GB. BitLocker sees this mismatch and refuses to encrypt – it's paranoid about data consistency, and honestly, it should be.
Cause #1: The Filesystem Didn't Follow the Partition Resize
This is the most common cause. You shrunk C: in Disk Management to make room for another partition, or you cloned a 240 GB SSD onto a 500 GB SSD without telling the filesystem to stretch. The partition gets bigger, but NTFS doesn't auto-expand to fill it – you have to explicitly tell it to. BitLocker then checks: "Does the filesystem end exactly where the partition ends?" Nope. Error thrown.
The Fix – Extend the Filesystem with diskpart
You need to extend the NTFS volume to actually use the space the partition provides. Here's the cleanest way, no reboots required:
- Open Command Prompt as Administrator. Don't skip this – diskpart needs admin rights.
- Type
diskpartand press Enter. - Type
list volume. Find the volume that's throwing the error. It's usually volume 0 (C:) or volume 1. Make note of the number. - Type
select volume X(replace X with the volume number). - Type
extend filesystem. This tells NTFS to expand into any unallocated space that's sitting after it inside the same partition. - Type
exittwice to close diskpart and the command prompt.
Why extend filesystem instead of just extend? The plain extend command tries to grow the partition itself, which might fail if there's data right after it. extend filesystem only touches the NTFS metadata – it's safer and exactly what we need here. Try BitLocker again. Nine times out of ten, that's it.
Cause #2: A Hidden Recovery Partition Is Blocking Extension
If extend filesystem gives you There is not enough usable free space, the partition itself might have unallocated space that isn't contiguous. A common scenario on Windows 10/11: a small recovery partition (around 500 MB) sits right after C:. You shrunk C: but the recovery partition is in the way, so the unallocated space ends up before that recovery partition, not after C:. diskpart can't extend into non-contiguous space.
The Fix – Move or Delete the Recovery Partition
This is trickier. You have two options:
- Option A – Delete the recovery partition (if it's not essential – e.g., on a secondary drive). Use Disk Management, delete the recovery partition, then run
extend filesystemagain. This works but you lose the recovery tools. On a system drive, I don't recommend this. - Option B – Use a third-party partition tool (like AOMEI Partition Assistant or MiniTool Partition Wizard) to move the recovery partition to the end of the disk. Then the unallocated space becomes contiguous after C:. These tools are reliable – I've used AOMEI on dozens of machines. Once moved, run
extend filesystemnormally.
If you're on a laptop with BitLocker already enabled on the OS drive, pause BitLocker first. Moving partitions can trigger recovery key prompts.
Cause #3: The Volume Was Shrunk Too Far and Left a Tiny Gap
Disk Management's shrink feature doesn't always shrink to the exact size you request. It leaves a small buffer that NTFS can't use – maybe 8 MB, maybe 100 MB. That buffer is unallocated space trapped inside the partition. The filesystem ends before that buffer, so extend filesystem sees nothing to extend into – but the partition is technically larger than the filesystem. BitLocker still complains.
The Fix – Align the End of the Filesystem
Run fsutil volume queryfs C: (or whatever drive letter) and look for Total Clusters and Free Clusters. If the free clusters are zero or tiny, the gap is hidden. The real fix here is to delete the partition and recreate it with the exact size, or use a tool that can shrink to the last sector. I prefer EaseUS Partition Master for this – its shrink function can go to the exact byte. Alternatively, you can boot from a Linux live USB and use gparted to shrink/resize more precisely. After resizing correctly, run extend filesystem and you're done.
Quick-Reference Summary Table
| Cause | Symptom | Fix |
|---|---|---|
| Filesystem not extended after resize | extend filesystem succeeds but error persists |
Run extend filesystem in diskpart |
| Recovery partition blocking contiguous space | extend filesystem fails with "not enough space" |
Move/delete recovery partition, then extend |
| Hidden gap from imprecise shrink | extend filesystem says "no space" but unallocated exists |
Use precise partition tool to eliminate gap |
One last thing: if you're on a Windows 11 system with BitLocker device encryption (the automatic kind that ties to your Microsoft account), you might need to decrypt first, apply the fix, then re-encrypt. That's a separate headache, but the root cause is still the filesystem not extending. The fix above handles it.
I've seen this error on Dell Latitude 7420s, HP EliteBooks, and custom-built desktops after cloning to a larger Samsung 870 EVO. Every time, it was cause #1. Try diskpart first – it's the least disruptive.
Was this solution helpful?