Repairing a WSL 2 ext4.vhdx Without Running e2fsck on a Mounted Filesystem

Each ordinary WSL 2 distribution stores its Linux filesystem in an ext4.vhdx virtual disk. If ext4 reports corruption or the distribution stops mounting, it is tempting to start another shell and run e2fsck against whatever device looks familiar. Repairing a mounted filesystem can make damage worse, and attaching the same VHDX through two active owners can corrupt it before the checker begins.

Microsoft documents a recovery path built around complete WSL shutdown, a backup, bare VHD attachment, device identification from another Linux environment, e2fsck, and explicit unmount. The exact VHD path and device name differ per system, so the procedure must discover them rather than copy a screenshot literally.

Confirm the symptom before changing bytes

Capture the error from wsl.exe -d <Distribution> and list registered distributions and their WSL versions. Check free space on the Windows volume holding the VHDX, because a full host disk can produce failures that resemble guest filesystem trouble.

wsl.exe --list --verbose
wsl.exe --status

If the distribution starts, copy irreplaceable files through normal WSL access before attempting repair. Application errors alone do not prove ext4 metadata is corrupt. A broken /etc/fstab, invalid WSL configuration, missing encryption key, or distribution startup command needs a different recovery.

Record the distribution name and package or import location. Do not search and operate on the first file named ext4.vhdx because Docker Desktop and other distributions may have their own disks.

Stop every WSL virtual machine owner

From an elevated PowerShell session, shut down WSL completely:

wsl.exe --shutdown

Close Windows Terminal tabs, IDE integrations, background services, and Docker Desktop if it uses WSL. Microsoft notes that Docker can hold the VHD and cause a sharing-violation error during repair. Confirm no distribution restarts automatically before copying or attaching the disk.

wsl --terminate for one distribution is not as strong as a full shutdown when the recovery depends on the WSL virtual machine and disk no longer being active. Use --shutdown and wait for processes to release their handles.

Make a cold backup of the VHDX

Copy the stopped ext4.vhdx to storage with enough free space. Preserve the original until repair and application checks pass. A filesystem checker intentionally rewrites metadata; even a correct repair may discard damaged objects to restore consistency.

Copy-Item "C:\Path\To\Distribution\LocalState\ext4.vhdx" "D:\WSL-Recovery\distribution-before-e2fsck.vhdx"

Hash the backup and record its size. Do not use a live cloud-sync directory that may partially upload or rewrite the large VHDX during the procedure. If copying fails because the file is in use, return to shutdown diagnosis instead of forcing access.

A backup of a corrupted filesystem is still valuable because a later tool or manual recovery may retrieve data that the first repair removes.

Attach the virtual disk without mounting ext4

Use WSL’s VHD mode and --bare so Windows attaches the disk but does not mount the Linux filesystem:

wsl.exe --mount "C:\Path\To\ext4.vhdx" --vhd --bare

The command exposes the virtual disk to WSL. It does not tell you to assume a fixed /dev/sdX name. Device assignment can change after reboot or as other disks attach.

If attachment reports that the file is already in use, stop and identify the owner. Do not duplicate the VHDX merely to bypass a sharing lock and then repair a copy while expecting the registered distribution to change.

Identify the device from a different distribution

Run lsblk inside a working WSL distribution and compare size, partitioning, filesystem type, and mount state. Microsoft’s guidance notes that a second distribution may be needed because the damaged distribution cannot be used to repair its own root.

wsl.exe -d Ubuntu-Recovery -- lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS

The target ext4 filesystem must have no mountpoint. If lsblk shows partitions, choose the ext4 partition, not blindly the whole disk. Recheck the expected VHDX size against the device.

Never run the next command until the mapping is unambiguous. /dev/sdc from one example may be the wrong disk on another machine or even on the next attempt.

Run e2fsck from the recovery distribution

Invoke the filesystem checker with root privileges against the confirmed unmounted device. Microsoft gives e2fsck -f as the repair command in this flow:

wsl.exe -d Ubuntu-Recovery -- sudo e2fsck -f /dev/sdX

Replace /dev/sdX with the actual ext4 device. Read every prompt. For automation, do not add unconditional yes flags until the backup is verified and the repair policy is understood. The checker may move disconnected objects into lost+found, clear invalid metadata, or report that manual action remains necessary.

Save the complete output. Run a second read/check pass if recommended and require a clean result before trying the original distribution. An I/O error may indicate a damaged VHDX or host storage problem that repeated metadata repair cannot solve.

Detach before restarting the distribution

When the checker finishes and no recovery shell has the device as its working directory, detach it through WSL:

wsl.exe --unmount "C:\Path\To\ext4.vhdx"

Use the form supported by the installed WSL version and verify the virtual disk disappears from lsblk. Then start the registered distribution normally. Do not launch it while the repair attachment remains active.

If unmount fails, close the recovery shell and identify open files. Forcing shutdown can be safer than leaving two owners, but retain the repair log and backup before any further transition.

Validate data above the filesystem layer

A clean ext4 check proves metadata consistency according to e2fsck. It does not prove every application database, package, or source file is semantically intact. Inspect dmesg, free space, /lost+found, important repositories, database integrity checks, and container volumes.

Export or back up the recovered distribution immediately. Compare important files with external copies and rotate secrets if corruption exposed private material into an unexpected recovered file location.

If the distribution remains unreliable, create a fresh distribution and recover data from the repaired VHDX read-only rather than repeatedly modifying the only installation.

Prevent the same recovery emergency

Keep host disk headroom, shut Windows down cleanly, update WSL, and maintain file-level backups outside the VHDX. wsl --export can provide a distribution backup, but test restoring it. A copied cold VHDX and a logical export serve different recovery needs.

Practice the attach-identify-check-unmount sequence with a disposable distribution. The dangerous part is not typing e2fsck; it is proving the selected block device is the stopped VHDX and ensuring no second owner mounts it during repair.

Related:

Sources: