Fix Linux Read-Only File System Error (EROFS)

The read-only file system error on Linux almost always means a dirty EXT4 partition or a failing drive. Here's how to force a clean remount and check the disk.

Quick answer

Run mount -o remount,rw /mountpoint to force a read-write remount. If that fails, you're dealing with a dirty filesystem and need to boot into recovery mode and run fsck -y.

The reason Linux mounts a filesystem read-only is simple: the kernel found something wrong and flipped the flag to prevent data corruption. Usually it's a dirty EXT4 partition—meaning the journal wasn't properly written when the system shut down or crashed. It can also be a failing drive that's started throwing I/O errors. The kernel's default response is to remount read-only, because writing to a broken disk makes things worse.

Step-by-step fix

Check the current mount state. Run mount | grep /mountpoint and look for ro in the options. Also check dmesg | tail for I/O errors or 'EXT4-fs error' messages. That tells you if it's a corruption issue or a hardware problem.
Try a forced remount.
```
sudo mount -o remount,rw /dev/sda1 /mountpoint
```
Replace /dev/sda1 and /mountpoint with your actual device and mount point. If it succeeds, you're done. But it rarely does when the system already flipped it to read-only—the kernel will likely refuse.
If the remount fails, reboot into recovery mode. Hold Shift during boot (or press Esc) to get the GRUB menu. Select 'Advanced options' then 'Recovery mode'. Pick 'Root' to get a shell. This gives you a minimal environment without mounting everything.
Run fsck on the unmounted filesystem. First identify the device: lsblk -f shows you which partition is ext4 or xfs. Then run:
```
fsck -y /dev/sda1
```
The -y flag answers 'yes' to all prompts—don't skip it, else you'll get stuck in a loop. It'll fix any journal errors and clear the dirty flag.
Reboot normally. After fsck finishes, type reboot. The system should mount the drive read-write now. Verify with mount | grep /mountpoint and look for rw.

If the main fix doesn't work

Sometimes fsck reports no errors but the system still mounts read-only. That's a hardware red flag. Check dmesg | grep -i 'read-only' and dmesg | grep -i error. If you see ATA errors or SMART failures, the drive is dying. Back up your data immediately and replace it.

For USB drives, especially cheap ones, the read-only state might be because the drive's own controller switched it to write-protect mode after detecting bad sectors. Try a different USB port or another computer to confirm. If it stays read-only across systems, the drive is toast.

Another scenario: a filesystem that fsck doesn't understand. If you're using XFS, Btrfs, or ZFS, the fix is different. For XFS, use xfs_repair instead of fsck. For Btrfs, mount with recovery option. But if you're just running a standard Ubuntu or CentOS install, EXT4 and fsck cover 90% of cases.

Prevention

Don't skip proper shutdowns. Use sync before unplugging external drives, and always safely eject. For internal drives, make sure your system's journal is healthy—run tune2fs -l /dev/sda1 | grep state to check the volume is 'clean'. If you see 'not clean', schedule a fsck with tune2fs -c 20 to check every 20 mounts.

Also, consider adding errors=remount-ro to your fstab options—it's the default on many distros, but if it's missing, the kernel might not remount read-only on error, which can lead to worse corruption. Better to fail safe.

Last thing: if you're running a Raspberry Pi or a system that frequently loses power, think about using a filesystem like F2FS that's designed for flash storage. It handles sudden power loss better than EXT4. But that's a bigger change, so only do it if you're building a fresh system.