Decrypting BitLocker Drive on Fedora

2025-07-07

# Decrypting BitLocker Drive on Fedora

So recently I went through a change of operating system where I moved from Windows 11 to Fedora 42.

I’d used Debian with GNOME on my laptop during university, but for some reason I went back to Windows using WSL. I had almost forgotten the difference in UX and performance. Memory-heavy IDE’s like Jetbrains Rider feels almost unusable on Windows in comparison.

After the transition I was embarrassed to find out that my auxiliary SSD drive was encrypted by Windows with BitLocker and I could not remember the passphrase.

Luckily, I had saved the recovery key in my password manager (Bitwarden ⬆️ ).

Now I had to find a way to decrypt the BitLocker-locked drive on my Fedora system.

First I tried a package called dislocker, but that didn’t work well. It actually segfaulted on me when I ran the command

sudo dislocker /dev/nvme1n1p2 -pXXXX-XXXXX-XXXXX-XXXXX-XXXXX -- /media/decrypt

Next, I found a thread that recommended using the program cryptsetup. It usually comes with systems that have LUKS (Linux Unified Key Setup). This program shipped with an extension called bitlk for working with BitLocker-encrypted partitions.

To prepare the open-command with bitlk, I placed my recovery key in a plain file bitlocker.key, making sure not to include any newline characters. I used the older syntax to provide the key, open the encrypted drive and give it the name aux-drive.

sudo cryptsetup bitlkOpen /dev/nvme1n1p2 aux-drive --key-file bitlocker.key

Then I proceeded to mount the resulting block device mapper file (placed in in /dev/mapper/) like so:

sudo mount /dev/mapper/aux-drive /mnt/aux

This partially failed though, with this debug message:

The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)
Could not mount read-write, trying read-only

The command returned a 0 exit code and the mount point was accessible, but the filesystem was indeed read-only.

Thank god for the wizards that create systems software like the utilities in the ntfs-3g package. Using the ntfsfix command, I could resolve this issue by running:

 sudo ntfsfix /dev/mapper/aux-drive
Mounting volume... The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/mapper/aux-drive was processed successfully.

What now remained was to setup an auto mount routine so that the drive is available when I restart my system.

Looking at the previously mentioned article, I found the suggestion to do it like this.

  1. Get the partition’s PARTUUID with sudo blkid -p /dev/<partition> Should spit out something like: /dev/nvme1n1p2: VERSION="2" TYPE="BitLocker" USAGE="crypto" PART_ENTRY_SCHEME="gpt" PART_ENTRY_NAME="Basic data partition" PART_ENTRY_UUID="8a8b2d25-b0c9-420d-af56-4f2c414e1049" PART_ENTRY_TYPE="ebd0a0a2-b9e5-4433-87c0-68b6b72699c7" PART_ENTRY_NUMBER="2" PART_ENTRY_OFFSET="32768" PART_ENTRY_SIZE="3906994176" PART_ENTRY_DISK="259:4"
  2. Run sudo nano /etc/crypttab and add a line with aux-drive PARTUUID=<your_part_uuid_here> <path_to_key_file_here> bitlk
  3. Edit /etc/fstab adding a line /dev/mapper/aux-drive /mnt/aux-drive ntfs defaults,nofail
  4. Test with sudo mount -a

However, I found that I’d actually want an entry that is more specific:

/dev/mapper/aux-drive /mnt/aux ntfs-3g rw,uid=1000,gid=1000,umask=022,nofail 0 0

# Conclusion

Moral of the story, save your recovery keys!