Fix Linux "Read-only file system" Error (EROFS)

You're mid-deploy at 2am, or worse — mid-rsync of a 400GB backup. Suddenly every write throws Read-only file system. touch /tmp/x fails. So does apt install, systemctl restart nginx, anything that touches disk. mount shows the root filesystem as ro when it should say rw. Nothing you typed caused this.

I've hit this on a 2013 MacBook Air running Ubuntu (dying SSD), on a Hetzner dedicated box with a bad SATA cable, and on a VM where the underlying host silently dropped the virtio-blk device. The trigger is almost always the same: the kernel caught a write error and pulled the emergency brake.

Why Linux remounts your disk read-only

This is a feature, not a bug — and the kernel is doing you a favor. When ext4, XFS, or Btrfs hits an unrecoverable I/O error (bad sector, cable fault, controller timeout, full LVM thin pool), it flips the filesystem to read-only to prevent corruption from spreading. Silently continuing to write to a disk that's dropping sectors is how you lose the whole volume.

Check dmesg and you'll see the smoking gun. Something like:

[ 4218.552041] EXT4-fs error (device sda1): ext4_journal_check_start:83: Detected aborted journal
[ 4218.552048] EXT4-fs (sda1): Remounting filesystem read-only
[ 4218.552052] sd 0:0:0:0: [sda] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 4218.552054] blk_update_request: I/O error, dev sda, sector 20480256

That Detected aborted journal line is the real story. Once the journal aborts, ext4 refuses to write. XFS says metadata I/O error instead. Btrfs logs parent transid verify failed. Same outcome.

The fix, step by step

You can't fsck a mounted filesystem. Any guide telling you to run e2fsck on a live root partition is wrong and can make things worse. Here's the actual order that works.

Save what you can. Copy anything critical off the box now, while reads still work. rsync -a /home/user/ backup-host:/backup/. Once you start fsck, you're playing with fire.
Try a remount first. Sometimes the error was transient (a single bad block, a flaky controller reset). If writes succeed after this, you dodged a bullet — but schedule a fsck anyway.
```
sudo mount -o remount,rw /
```
If it comes back with mount: /: cannot remount /dev/sda1 read-write, is write-protected, keep going.
Figure out the block device. Run findmnt / or lsblk -f. On LVM you'll see something like /dev/mapper/vg0-root. You need the actual device, not the mountpoint.
Boot into rescue mode. From a live USB, a cloud provider's rescue console (Hetzner rescue, OVH rescue-pro, DigitalOcean recovery ISO), or single-user mode with systemd.unit=rescue.target appended to the kernel line in GRUB. The filesystem must not be mounted.
Unmount if auto-mounted.
```
sudo umount /dev/sda1
```
If it says "target is busy," sudo lsof +f -- /dev/sda1 and kill what's holding it. Live CDs sometimes auto-mount — check findmnt.
Run the right fsck for your filesystem. Don't guess.
```
# ext4
sudo e2fsck -f -y /dev/sda1

# xfs (won't run on a mounted or dirty log)
sudo xfs_repair /dev/sda1

# btrfs
sudo btrfs check --repair /dev/sda1
```
The -f forces a check even if the superblock says clean. The -y answers yes to prompts — fine for recovery, terrible for curiosity. On XFS, if xfs_repair complains about a dirty log, add -L to zero it, but only if you understand that means losing anything not yet written to the journal.
Reboot and remount. If fsck exits clean, boot normally. Check dmesg | tail -50 for new errors. If they're gone, done.

If fsck reports it fixed things, do a second pass without -y to confirm. Running it twice is normal; the first pass repairs, the second verifies. Don't skip this.

If it still comes back read-only

Persistent read-only after a clean fsck usually means one of these:

Hardware is dying. Check smartctl -a /dev/sda. Look at Reallocated_Sector_Ct, Pending_Sector_Ct, and Offline_Uncorrectable. Anything nonzero and climbing means the drive is on its way out. Replace it before you spend more time on software fixes.
Fstab has errors=remount-ro and you're hitting a new error. It's doing its job. Fix the underlying disk, not the mount option.
Cloud volume detached or throttled. On AWS, an EBS volume that hits its IOPS or throughput limit can return errors that make the kernel remount read-only. Check CloudWatch burst balance. On Hetzner Cloud, a full / volume on a shared host can behave the same way.
LVM thin pool is full. lvs will show Data% at 100%. Extend the pool: lvextend -L +10G vg0/thinpool. The filesystem will happily remount rw afterward.

One last thing: if the drive is genuinely failing, ddrescue the data off before running any more fsck. Every fsck pass stresses a dying disk. Image first, repair the image, then move the data.