Fix 'Read-only file system' Linux error

Quick answer

Run mount -o remount,rw /mountpoint as root. If it fails, check dmesg for I/O errors, run fsck on the underlying device, and remount again.

What's actually happening here is the kernel flipped the filesystem to read-only as a protective measure. It doesn't do this randomly — it happens after the filesystem driver detects a condition it considers unsafe for writes. The most common triggers are unrecovered journal errors on ext4, disk I/O failures, or a forced unmount from a network filesystem like NFS.

The reason you can't just write to it again is that the kernel marks the superblock as needing a clean remount. So the fix is two-fold: remount it read-write, and then find out why it went read-only in the first place. Ignoring the second half guarantees you'll see the error again.

The numbered fix steps

Identify the mount point. Run findmnt -t ext4,xfs,btrfs,nfs,cifs or just mount | grep ro to see what's showing ro in the options.
Check the kernel logs. This is the step most people skip, and it's the one that tells you what broke. Run dmesg | tail -50 and look for lines mentioning your device (e.g., sda1), filesystem type, or phrases like I/O error, remounting read-only, or EXT4-fs error.
Try a clean remount. If the logs show nothing fatal, do: mount -o remount,rw /mountpoint. This works if the filesystem wasn't marked as needing an fsck.
Force a remount if the above fails. Sometimes the kernel refuses because it thinks the device is busy. Use mount -o remount,rw /mountpoint 2>/dev/null || echo "Remount failed". If it says “Mount is denied because the NTFS volume is already exclusively opened” — that's a different problem, but for ext4/xfs it rarely blocks a remount.
Unmount and mount again. If a remount won't take, do umount /mountpoint then mount /mountpoint. Be careful — if the filesystem has pending writes, unmounting might fail. Use lsof +f -- /mountpoint to find processes holding it, kill them, then unmount.
Run fsck on the raw device. This is the real fix for corrupted superblocks or journal errors. First unmount the filesystem, then run fsck -f /dev/sdXY (replace with your device). For ext4, the journal replay might need e2fsck -fy /dev/sdXY. Do this from a live USB if the filesystem is your root partition, because you can't fsck a mounted root.
Remount after fsck. Once fsck reports clean, mount it back up with mount /mountpoint and verify with mount | grep rw.

Why your root filesystem goes read-only

The typical scenario: you're working on a server, and suddenly touch /etc/test gives “Read-only file system”. You check mount and see /dev/sda1 on / type ext4 (ro,relatime). The kernel did that because the ext4 driver hit an error it couldn't recover from — often a bad sector, a failed disk, or a power loss that left the journal in an inconsistent state.

What's happening behind the scenes is the ext4_handle_error() function in the kernel. It decides the filesystem is no longer trustworthy for writes, so it forces a read-only remount to prevent further corruption. That's actually a smart design — it stops you from writing to a filesystem that might be silently corrupting data.

But sometimes the trigger is benign. For example, if you're running a filesystem on a USB stick that got disconnected and reconnected, the kernel might see a brief I/O timeout and remount RO. In that case, a simple remount works. On NFS, a server reboot can cause similar symptoms; the fix there is to unmount and remount the NFS share, not to fsck the client's disk.

Alternative fixes when the main one fails

If fsck can't fix it — check the hardware

If e2fsck reports bad blocks and suggests reallocating, run smartctl -a /dev/sdXY (from smartmontools) to check the disk's health. A disk with reallocated sectors or pending sectors is dying. Back up your data immediately. No amount of remounting will help if the physical disk is failing.

If it's a systemd mount unit

For mounts defined in /etc/fstab or as systemd units, sometimes the mount unit gets into a failed state. Run systemctl status mountpoint.mount (replace with the escaped mount path) and then systemctl restart mountpoint.mount. You might also need to run systemctl daemon-reload if you changed fstab.

If the filesystem is btrfs

Btrfs handles read-only differently. If you see btrfs: error ... in dmesg, try btrfs device scan first. Then mount with mount -o remount,rw /mountpoint. If that fails, you might have to mount with degraded if a device dropped out, but only if you're okay with running in a degraded state temporarily.

If you're on ZFS

ZFS exports get set read-only if the pool hits an error. The fix is to zpool clear the pool after fixing the underlying cause, then zfs set readonly=off pool/dataset. But running zpool import -F might be needed if the pool was force-exported.

Preventing the recurrence

The single best prevention: monitor your disk health before it fails. Set up a cron job to run smartctl -a /dev/sda weekly and check for FAILING_NOW or Reallocated_Sector_Ct increasing. Also make sure your system shuts down cleanly — a UPS helps more than you'd think, because power loss is a leading cause of journal corruption on desktops and small servers.

For filesystems you can't afford to lose, consider using a filesystem with better checksumming like btrfs or ZFS, but know their tradeoffs. And don't ignore dmesg warnings — if the kernel says a block device had an error, it's not being dramatic. By the time you see the read-only error, the disk has usually been struggling for a while.

The read-only remount is your filesystem screaming for help. Listen to it before it goes silent.