Fix 'Read-only file system' on Linux (EROFS errno 30)

Quick answer

Run mount -o remount,rw / to get writes back immediately, then check dmesg for the I/O error that caused the kernel to flip the filesystem read-only in the first place. If dmesg shows EXT4-fs errors, unmount and run fsck -f on the device.

Why this happens

You're in the middle of an apt upgrade, or writing a 40 GB Postgres dump to /var/lib/postgresql, and suddenly every command spits out Read-only file system. Touch does nothing. mkdir fails. The error code under the hood is EROFS, errno 30, and it's telling you the kernel already made a decision on your behalf.

By default, ext4 mounts with errors=remount-ro. That option is set in tune2fs output and most distros ship with it. When the filesystem hits a metadata inconsistency, or the block layer reports a device I/O error, the kernel doesn't keep limping along writing garbage to your disk. It flips the mount to read-only to protect the data that's still intact. The real fix is almost never just remounting rw and walking away. You need to find what triggered the flip.

The most common real-world triggers I see on the help desk:

A dying SSD or spinning disk — dmesg shows ata1.00: failed command: WRITE FPDMA QUEUED or I/O error, dev sda, sector 1234567.
Full LVM snapshot that filled up — the COW store hit 100% and ext4 threw a metadata error.
Pull the power mid-write on a Raspberry Pi with a flaky SD card. Classic. You reboot and root comes up read-only in emergency mode.
Corrupt journal after a VM host crashed. The guest boots, sees the journal is inconsistent, and remounts ro.

Fix it step by step

Confirm it's actually read-only. Run:
```
mount | grep ' / '
```
You should see something like /dev/sda2 on / type ext4 (ro,relatime). That ro is the problem. If it says rw, the error is coming from a subdirectory that's on a different mount, so check df /path/to/wherever.
Check dmesg before doing anything else. This is the step people skip and it's the one that matters.
```
dmesg -T | tail -n 100
```
Look for lines starting with EXT4-fs error, blk_update_request: I/O error, or sd 0:0:0:0: [sda]. If you see I/O errors, skip ahead to the disk health section. If you only see EXT4-fs (sda2): Remounting filesystem read-only with no I/O errors, it's a metadata issue and fsck will probably fix it.
Remount rw to get back in.
```
sudo mount -o remount,rw /
```
If it succeeds, the prompt returns with no output. Try touch /tmp/test.txt to verify. If it fails with mount: /: cannot remount /dev/sda2 read-write, is write-protected, the block device itself is write-protected — usually a hardware fault or a VM disk that got detached.
If the root filesystem won't remount, drop to single-user mode. Reboot and edit the GRUB entry. Add single or init=/bin/bash to the kernel line. At the prompt:
```
mount -o remount,rw /
fsck -f /dev/sda2
```
Answer y to the fix prompts. fsck wants the filesystem unmounted — remounting rw first is a workaround if you can't get a rescue disk, but the clean version is to boot a live USB, run fsck -f /dev/sda2 there, and reboot.
Reboot cleanly.
```
sudo reboot
```
After the reboot, run mount | grep ' / ' again. You want rw in the flags. If it comes up ro again, the kernel found another inconsistency on mount and you've got a bigger problem — likely physical.

If that doesn't work

If fsck keeps finding errors on every boot, or the remount fails, work through these:

Check the disk itself. Run sudo smartctl -a /dev/sda. Look at Reallocated_Sector_Ct, Current_Pending_Sector, and Offline_Uncorrectable. Anything above zero on the last two means sectors are dying. Back up your data now, before you do anything else.
Test the write protect flag. sudo hdparm -r /dev/sda shows whether the device is set read-only. Clear it with sudo hdparm -r0 /dev/sda. This bites people on USB sticks and SD cards that flipped their write-protect bit.
Check the journal. sudo dumpe2fs -h /dev/sda2 | grep -i journal. If the journal size is 0, ext4 fell back to a no-journal mount, and that's a sign of severe corruption.
Mount with errors=continue temporarily. Only if you need to pull data off before replacing the disk. Set it with sudo tune2fs -e continue /dev/sda2. Put it back to errors=remount-ro when you're done. Do not leave a production box on continue — you'll silently corrupt more data.
On a VM, check the hypervisor. If this is a KVM or VMware guest, the virtual disk may have gone read-only because the host datastore filled up. That's a common gotcha in Proxmox when a thin-provisioned LVM volume hits the ceiling.

Prevention

Keep an eye on disk health before it becomes a 3 AM pager. Schedule smartctl -H /dev/sda in cron and alert on failures. Set up smartd and a notification hook so you hear about pending sectors days before the kernel flips your root to ro.

Don't yank power on a Pi or any SBC with a cheap SD card. Ext4's journal is good but it isn't magic — a mid-write power cut is the number one cause of read-only root on hobby hardware. If you're running anything important on a Pi, boot from USB SSD instead.

Also, watch LVM snapshot usage. Snapshots that fill up will silently corrupt the origin volume's metadata. Monitor with lvs -o lv_name,snap_percent and keep snapshots under 80% full.