WSL2 File System Goes Into Read Only Mode Without Warning

[jhoweaa]

Version

Microsoft Windows [Version 10.0.19043.1645]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.16

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

I have no specific steps. One minute things are fine, the next minute my file system is read only. If I do a wsl --shutdown, the next time I open a WSL session the file system work again, but it seems within a few minutes the file system will lock again.

Expected Behavior

I am not expecting the file system to randomly go into read-only mode.

Actual Behavior

The file system randomly goes into read-only mode. If I run wsl --shutdown from Powershell and then open a new WSL session, the file system goes back to read/write. I suspect some sort of file system error from information I see in the dmesg output. I'm running WSL2 on a new laptop with a 500gb SSD with approximately 170gb free. I've seen other responses to a similar problem with people suggesting running e2fsck, but I can't run that command because the file system is mounted.

Some additional information:

I'm running WSL but accessing the file system with both IntelliJ and VS Code from Windows. I'm using the VS Code Remote capabilities and IntelliJ has something similar that allows it to work with WSL files from the Windows application. I'm also using typical tools like git from within the WSL environment. I also have Docker Desktop running.

I've found some instructions elsewhere that describe how to mount the device ro, run e2fsck, and remount the device, i.e.

root@PC1:~# e2label /dev/sdb cloudimg-rootfs
root@PC1:~# mount -o ro,remount /
root@PC1:~# e2fsck /dev/sdb
e2fsck 1.45.5 (07-Jan-2020)
cloudimg-rootfs has been mounted 614 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
cloudimg-rootfs: 310833/16777216 files (0.2% non-contiguous), 3430176/67108864 blocks
root@PC1:~# mount -o rw,remount /

but I could never get the unmount to work since it told me the mount point was busy.

I guess my main question is, how do you 'repair' a WSL disk? I can't run fsck on a mounted volume, but I can't unmount it because I won't be able to access it. There must be some way to do this.

Diagnostic Logs

The partial content of sudo dmesg -w looks like this:

[  276.408413] WSL2: Performing memory compaction.
[  284.871120] init: (1) WARNING: /etc/resolv.conf updating disabled in /etc/wsl.conf
[  305.156564] EXT4-fs (sdb): error count since last fsck: 11
[  305.156566] EXT4-fs (sdb): initial error at time 1651077526: __ext4_find_entry:1545: inode 763869
[  305.156567] EXT4-fs (sdb): last error at time 1651087703: ext4_lookup:1706: inode 776830
[  337.604860] WSL2: Performing memory compaction.
[  398.614378] WSL2: Performing memory compaction.
[  459.622795] WSL2: Performing memory compaction.
[  469.456793] init: (1) WARNING: /etc/resolv.conf updating disabled in /etc/wsl.conf
[  485.249625] init: (1) WARNING: /etc/resolv.conf updating disabled in /etc/wsl.conf
[  485.779282] init: (1) WARNING: /etc/resolv.conf updating disabled in /etc/wsl.conf
[  485.918674] init: (1) WARNING: /etc/resolv.conf updating disabled in /etc/wsl.conf
[  528.635827] WSL2: Performing memory compaction.
[  589.795014] WSL2: Performing memory compaction.
[  613.979355] EXT4-fs error (device sdb): __ext4_find_entry:1545: inode #763869: comm npm: checksumming directory block 0
[  613.980446] Aborting journal on device sdb-8.
[  613.981955] EXT4-fs (sdb): Remounting filesystem read-only
[  613.982141] EXT4-fs error (device sdb): __ext4_find_entry:1545: inode #763869: comm npm: checksumming directory block 0
[  613.982503] EXT4-fs error (device sdb): ext4_journal_check_start:83: Detected aborted journal
[  650.824629] WSL2: Performing memory compaction.
[  652.345978] init: (1626) ERROR: InitCreateProcessUtilityVm:1909: write failed 32
[  654.694723] init: (4411) ERROR: InitCreateProcessUtilityVm:1909: write failed 32
[  658.325894] init: (1) WARNING: /etc/resolv.conf updating disabled in /etc/wsl.conf
[  711.851356] WSL2: Performing memory compaction.
[  850.677654] init: (1) WARNING: /etc/resolv.conf updating disabled in /etc/wsl.conf
[  892.956299] WSL2: Performing memory compaction.

After closing all WSL windows and performing a wsl --shutdown, when I restart my Ubuntu environment, I see this in the dmesg logs:

2022-04-28T11:30:11,723882-04:00 EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: discard,errors=remount-ro,data=ordered
2022-04-28T11:30:14,931880-04:00 EXT4-fs warning (device sdb): ext4_clear_journal_err:5610: Filesystem error recorded from previous mount: IO failure
2022-04-28T11:30:14,931882-04:00 EXT4-fs warning (device sdb): ext4_clear_journal_err:5612: Marking fs in need of filesystem check.
2022-04-28T11:30:14,933049-04:00 EXT4-fs (sdb): warning: mounting fs with errors, running e2fsck is recommended
2022-04-28T11:30:14,934465-04:00 EXT4-fs (sdb): Errors on filesystem, clearing orphan list.
2022-04-28T11:30:14,934466-04:00 EXT4-fs (sdb): recovery complete
2022-04-28T11:30:14,934994-04:00 EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: discard,errors=remount-ro,data=ordered
2022-04-28T11:30:16,865632-04:00 EXT4-fs (sdc): recovery complete
2022-04-28T11:30:16,866089-04:00 EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: discard,errors=remount-ro,data=ordered
2022-04-28T11:30:25,752282-04:00 EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: discard,errors=remount-ro,data=ordered
2022-04-28T11:30:26,456680-04:00 EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: discard,errors=remount-ro,data=ordered
2022-04-28T11:30:26,892962-04:00 EXT4-fs (sdd): recovery complete
2022-04-28T11:30:26,893570-04:00 EXT4-fs (sdd): mounted filesystem with ordered data mode. Opts: discard,errors=remount-ro,data=ordered

[jhoweaa]

I guess at least one solution is to wait until the system goes into readonly mode and then run the sudo e2fsck command with -f

[0xbadfca11]

Attach VHD without mount on other distros, and run e2fsck.

[jhoweaa]

Attach VHD without mount on other distros, and run e2fsck.

Unfortunately my environment doesn't seem to have the wsl --mount command available. I was going to try this, but wasn't successful.

[OneBlue]

It indeed looks like the VHD is corrupted and needs e2fsck. If wsl --mount is not available, creating a linux VM and manually attaching the VHD manually so e2fsck can run should work.

If not, I'd recommend updating to a build that supports wsl --mount.

[cpriest]

I was able to fix this issue by running ...\com.docker.backend.exe -reset_wsl, I had backed up my WSL instance with wsl -export ... but it wasn't needed.

After that it came back up just fine.