Mounting Physical Linux Disks in WSL 2 Without Damaging Them

wsl --mount lets a WSL 2 distribution access a physical disk or partition directly — genuinely useful for recovering data from a Linux-formatted drive, inspecting a disk image, or working with a filesystem Windows itself can’t read natively. It’s also an operation involving real, physical storage, where a wrong step risks actual data loss rather than merely a broken software configuration you can simply reconfigure and retry.

Start by identifying the disk correctly in Windows

Before touching WSL at all, identify the target disk from the Windows side and confirm you have the right one:

Get-Disk

Cross-check the disk number against its reported size and any identifying information (partition layout, existing volume labels) rather than guessing based on size alone — mounting the wrong disk because two drives happen to be similarly sized is an entirely avoidable mistake with potentially serious consequences if you proceed to write to it.

Back up anything irreplaceable before proceeding

If the disk contains data you can’t afford to lose and haven’t already backed up elsewhere, do that first. Disk-level operations, filesystem drivers handling an unfamiliar or damaged filesystem, and cross-platform tooling in general all carry more inherent risk than routine file operations on an already-trusted, already-backed-up filesystem — treat this step as mandatory, not optional, for any disk holding data you actually care about.

Understand that a disk can’t serve two masters at once

A disk can’t be simultaneously mounted for normal Windows use (appearing as an ordinary drive letter, accessible to Windows applications) and handed to WSL for direct access. If the disk is currently mounted and in use on the Windows side, take it offline from Windows first:

Get-Disk | Where-Object DiskNumber -eq <N> | Set-Disk -IsOffline $true

Start with read-only access for anything unfamiliar or potentially damaged

When you’re investigating a disk whose filesystem health or exact contents you’re not fully certain of, mounting read-only avoids the possibility of a filesystem driver’s write path making a marginal or already-damaged filesystem worse while you’re just trying to look at it:

wsl --mount \\.\PHYSICALDRIVE<N> --bare

then, from inside the distribution, mount the specific partition explicitly as read-only using the filesystem type you’ve confirmed it actually uses, rather than assuming.

Using the current, documented mount syntax for your filesystem

wsl --mount \\.\PHYSICALDRIVE<N> --partition <P> --type ext4

Filesystem type support varies by WSL version and by what kernel modules are actually available — confirm current syntax and supported filesystem types against Microsoft’s documentation for your installed version rather than copying a command from an older article that may reference options no longer accurate for your setup.

Verifying from inside Linux before writing anything

Once mounted, confirm the device and filesystem look as expected from the Linux side before performing any write operation:

lsblk
sudo file -s /dev/sdX1

Confirming the reported filesystem type and partition layout match what you expected from the Windows-side identification step catches a mismatch before it becomes a mistake, rather than after.

When the filesystem needs tooling WSL doesn’t have

Some filesystems require kernel modules or encryption tooling (certain proprietary or less common filesystem types, or an encrypted volume needing specific unlock tooling) that the standard WSL kernel doesn’t include by default. If mounting fails or the filesystem isn’t recognized, that’s a signal to use a purpose-built recovery environment or a custom WSL kernel built with the needed module, rather than assuming the disk itself is damaged.

Detaching cleanly, in the correct order

sudo umount /mnt/wsl/PHYSICALDRIVE<N>p<P>

wsl --unmount \\.\PHYSICALDRIVE<N>

Unmount from inside Linux first, then detach from the WSL/Windows side, and only then physically disconnect any removable hardware. Disconnecting out of this order — especially unplugging hardware before a clean unmount completes — risks leaving the filesystem in an inconsistent state, exactly the kind of damage this careful procedure exists to avoid.

Never guess a disk number from size alone under time pressure

The single most avoidable mistake in this entire procedure is skipping the identification step because two disks look similar or because you’re in a hurry — confirm the disk number explicitly every time, especially on a machine with multiple similarly-sized drives attached, before running any command that mounts, offlines, or writes to it.

Bringing the disk back online in Windows afterward

If the disk needs to return to normal Windows use once you’re done, set it back online explicitly rather than leaving it in an ambiguous offline state:

Get-Disk | Where-Object DiskNumber -eq <N> | Set-Disk -IsOffline $false

Confirm it reappears correctly in File Explorer before considering the whole procedure complete.

Related:

Sources: