If you have a LUKS-encrypted partition on another disk, it's easy to mount it inside WSL.
List your disks:
> wmic diskdrive list brief
Mount the whole disk inside WSL (using --bare
so WSL doesn't attempt to mount it automatically):
> wsl --mount \\.\PHYSICALDRIVE1 --bare
Now inside WSL, check the device name of the mounted disk (something like /dev/sd*
):
$ dmesg | tail
Open the LUKS device (it'll prompt for your passphrase):
$ sudo cryptsetup luksOpen /dev/sdd3 my-encrypted-disk
And mount it somewhere:
$ sudo mount /dev/mapper/my-encrypted-disk /somewhere
Avoid mounting on /mnt
because that's usually used by WSL itself to mount your C:
drive.
Important Update: Cautionary Advisory on Using WSL with Multiple LUKS-Encrypted Drives
For those diving into integrating WSL with
cryptsetup
and LUKS-encrypted drives, I cannot stress enough the paramount importance of backing up the LUKS header. I recently encountered an issue where Windows inadvertently introduced a 16MB GPT header to my drive. This action put my entire 16TB drive at risk.This anomaly presented itself upon connecting a Funtoo SSD, housing three partitions:
Upon further examination, I identified that this GPT overwrite potentially stemmed from interactions between the SSD and a connected USB drive. My proactive decision to back up the LUKS header was the sole reason I managed to restore and access my data. Without this precaution, the outcome might have been irrevocably dire.
Should you be considering a similar WSL setup, I earnestly urge you to make a LUKS header backup prior to any integration or modification steps. The inherent risks are significant, and a pre-emptive backup could be the pivotal factor between a successful recovery and irreplaceable data loss.
Technical Insight without modifcations:
Key Observations:
{"keyslots": ...
corresponds to the LUKS2 header configuration. This data delineates encrypted content unlocking protocols, algorithms employed, key derivation specifics, and more. The LUKS data's lingering presence implies the GPT header didn't completely overwrite the original LUKS2 header. This partial preservation, combined with my backup, facilitated the successful data recovery.This incident highlights the significance of prudence when working with raw disk tools. Even minimal, unintended alterations can culminate in data access barriers or outright loss. Vigilant backup practices, especially concerning vital headers or metadata, are indispensable.