WSL disk cannot be mounted read-write

[Toufukun]

After a BSoD (not caused by WSL), my WSL disk won't be mounted read-write by default, and I can't remount it manually.

Environment

Windows build number: 10.0.19041.0
Your Distribution version: Ubuntu 20.04 LTS
Whether the issue is on WSL 2 and/or WSL 1: WSL 2

Steps to reproduce

(This issue is unique to my system, maybe unable to reproduce.)

sudo mount -o rw,remount /
mkdir ~/foo

Expected behavior

Disk will be mounted read-write. You will create a folder in your home directory.

Actual behavior

I can't create files or folders anywhere in WSL. When I use sudo mount -o rw,remount / to remount the disk, it prompts:

mount: /: can't find LABEL=cloudimg-rootfs.

I tried sudo e2label /dev/sdb cloudimg-rootfs, and remount it again, then:

mount: /: cannot remount /dev/sdb read-write, is write-protected.

So I tried sudo hdparm -r0 /dev/sdb, and remount it again. It doesn't work, still giving the same prompt.

[therealkenc]

Likely your ext4 filesystem on the VHD is corrupt, causing it to be (forcibly) mounted ro. Kind of cool that Ubuntu launched though. You can confirm with dumpe2fs(8) (sudo dumpe2fs -h /dev/sdb). Look at the "Filesystem state". If the filesystem isn't clean then it can't be mounted rw, by-design Linux.

I can't think of a way for you to run e2fsck(8) on /dev/sda /dev/sdb with conventional weapons. Sane way out would be tar(1) up your /home to /mnt/c/Users/you (which looks mounted above) and re-install the distribution from the Store. You could try doing a wsl.exe --export and then --import it, although even if that (scary quote) "works", it wouldn't be how I'd roll.

Seems like this could be parlayed into feature request "wsl.exe -d <distro> fsck" under a different cover. Or maybe house-brand /init could attempt an auto-fsck by fiat.

[Toufukun]

@therealkenc Strangely my main disk is /dev/sdb, and my /dev/sda is a swap. dumpe2fs showed my filesystem state was "clean with errors". Was I lucky enough to get Ubuntu running? Then I tried e2fsck. It showed me a lot of errors, so I used sudo e2fsck -y /dev/sdb to let it automatically fix all the errors. After rebooting, it does mount the disk read-write, but it is very dangerous. Before I can compile something, my WSL crashed several times and forced my Windows Terminal to quit. I think the best way still is copying all my files out and reinstalling the distribution, like you said.

Do you mean it can be built into a feature to allow user run fsck outside Linux shells, or even run it when the subsystem starts? That seems helpful.

I never know WSL2 runs like a virtual machine. Can I suspend it, for example, pausing it when running a time-consuming task to relese the hardware resources for other programs?

[therealkenc]

my main disk is /dev/sdb

Sorry that was just fingers without actually looking. The root mount is /dev/sdb (keep being you, WSL).

Then I tried e2fsck.

I assumed, incorrectly, that you wouldn't be able to run e2fsk with /dev/sdb already mounted. It was worth a try.

Do you mean it can be built into a feature to allow user run fsck outside Linux shells, or even run it when the subsystem starts?

That was the idea. But having a wsl.exe --fsck isn't necessary if you were able to run it on the ro mount. You accomplished the same thing.

...it does mount the disk read-write...my WSL crashed several times

That sounds about right. Happy you were able to clear the ro flag at least. Closing "corrupt VHD".

[Toufukun]

@therealkenc Thank you for your help. e2fsck indeed did its job. In fact, I can e2fsck a disk in good status if I remount it read-only. I can even sudo mount -o ro,remount / while keep the WSL running.

[the-supercoach]

Hi All,
Is it possible to have this solution moved to the official WSL documentation somewhere? I've been struggling with disk problems all week and ended up in a loop where I could restart WSL, but as soon as I tried to do anything meaningful, the OS would encounter an error and reload itself RO. It turns out that the read only mount was exactly what I needed and after noting the success had here, I tried running e2fsck when the disk was mounted RO which was exactly what I needed.
I'm sure there's others who have encountered the same problem, so hopefully suggesting running a fsck on any disk that mounts itself read only will save people some headaches.
Thanks :)

[therealkenc]

Is it possible to have this solution moved to the official WSL documentation somewhere?

Doc requests and PRs here. In principle a feature request could be opened for WSL /init to do the repair ref #4833 (message). In the case that the fs is corrupted, WSL already knows this happened, so making the user websearch to find the fix in the documentation is (at least arguably) an unnecessary extra step.

[Myron-S]

TL;DR

Reading this lot give me a headache. Below is what worked on ....
Linux 5.4.91-microsoft-standard-WSL2 #1 SMP Mon Jan 25 18:39:31 UTC 2021 x86_64 x86_64

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 /

[dcharlespyle]

I tried to run mount -o ro,remount / and got: mount: /: mount point is busy.

I try to run umount -a and I get the following:

umount: /mnt/c: target is busy.
umount: /run: target is busy.
umount: /dev: target is busy.
umount: /init: target is busy.
umount: /: target is busy.

[dhoke4tdb]

in event this would be helpful to others, dumpe2fs was reporting "clean" state, while subsequently running e2fsck reported errors.

was trying to use 'native' docker in wsl2 ubuntu 20.04 installation, was having issues that led to discovery of read-only issue

sudo mount -o remount,rw /
(resulted in the errors reported elsewhere of mount: /: cant find LABEL=cloudimg-rootfs)

dumpe2fs /dev/sdc (was 'sdc' initially) showed device was in "clean" state, but apparently it was not.

Generally following Myron-S initial steps

(service docker stop - to get rid of extra mount of /dev/sdc to /var/lib/docker)
e2label /dev/sdc cloudimg-rootfs
mount -o remount,ro /
e2fsck /dev/sdc
(***reported errors in block count**)
Fix<y>: (or whatever the prompts look like)
(took default answer)
(tool reported changes, and that system needed to be rebooted)
(shutdown didn't work, went through whole process again, simply exiting didn't work,
finally from another cmd window did)
wsl --terminate <the wsl distribution I was running with ro filesystem issues>
(it exited within the cmd window where I had it running,
and I restarted the distribution)
mount -v
(showed / now mounted from /dev/sdb as rw, and after restarting the docker service, my docker-compose worked.)

[Myron-S]

I could not do anything with the rootfs block device if it didn't have a label. Once I assigned a label to the block device I could mount ro and e2fsck it.

Never force a e2fsck on a rw mounted block device as doing so could result in e2fsck corrupting beyond recovery the file system it is trying to fix.

It's a procedure I performed on a Western Digital NAS that just flat refused to invoke e2fsck on reboot on its rootfs even though the volume was flagged as dirty.

linux shutdown does not work on WSL. Thats the job of the wsl --terminate command.

[dhoke4tdb]

Never force a e2fsck on a rw mounted block device as doing so could result in e2fsck corrupting beyond recovery the file system it is trying to fix.

Following your steps, I had re-mounted ro before e2fsck.

Think main difference between what you reported and what I observed is that errors were reported as found and fixed to me,
your output does not show any errors, just that volume was out-of-date and needed to be checked,
and after fixes, I was told a 'reboot' was necessary, there was no indication a remount,rw would work for me, (and don't recall, but don't think I tried.)

You apparently were able to remount,rw without 'reboot'ing, possibly (?) because there weren't actually any errors found in your case.

linux shutdown does not work on WSL. Thats the job of the wsl --terminate command.

noted

[brucejo75]

You could have an inconsistency in /etc/fstab because WSL can use different devices for the root file system on reboot.

See #6220 (comment)