Fixing "Read-only file system" Errors - Remount and fsck

2026-06-05 Reading time: About 11 min Difficulty: Intermediate

What does "Read-only file system" actually mean?

Conclusion: Writes are rejected with Read-only file system (EROFS). Either the mount is intentionally ro, or the kernel detected I/O errors and protectively demoted the filesystem to read-only.

Saving in vi, a touch, or a log write fails like this:

touch: cannot touch '/var/log/app.log': Read-only file system

There are three broad causes. Triage them in this order of priority.

A. Kernel demoted it to ro on error (most important) — ext4's default errors=remount-ro automatically drops the filesystem to read-only when it detects I/O errors or metadata corruption, as a protection
B. Intentional ro mount — an ro entry in /etc/fstab, a CD-ROM/SquashFS, or a read-only container volume
C. Filesystem corruption — inconsistencies that need fsck; usually surfaces via A

The key call first: in case A the disk may be failing underneath. Before you write back with remount,rw, always check dmesg for hardware I/O errors.

How do you check the current state?

Conclusion: Confirm the target is really ro with findmnt, then use dmesg to identify why it went ro — an I/O error, metadata corruption, or just config. Never write back before knowing the cause.

1. Confirm it is actually read-only

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /

TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda1 ext4   ro,relatime,errors=remount-ro

If OPTIONS starts with ro, it is read-only. You can also read /proc/mounts directly.

grep ' / ' /proc/mounts

2. Find out why with `dmesg`

This is the heart of triage. Whether hardware I/O errors appear here decides your next move.

dmesg -T | grep -iE 'ext4-fs|i/o error|remount|read-only|critical'

[Thu Jun  5 09:12:44 2026] EXT4-fs error (device sda1): ext4_journal_check_start:84: Detected aborted journal
[Thu Jun  5 09:12:44 2026] EXT4-fs (sda1): Remounting filesystem read-only
[Thu Jun  5 09:12:43 2026] blk_update_request: I/O error, dev sda, sector 12869632

I/O error / blk_update_request present → suspect disk failure (below)
EXT4-fs error only, no hardware I/O error → corruption; fsck needed (below)
Nothing at all → config-driven ro; check /etc/fstab

journalctl -k -b shows the same kernel log. Unlike dmesg, which clears on reboot, it can reach prior boots (-b -1, etc.).

How do you get back to read-write? (remount)

Conclusion: For config-driven or mild transient cases, mount -o remount,rw / restores it immediately. But when the cause is an I/O error or corruption, writing back is dangerous — do this only after the dmesg check.

Run this only once you have confirmed the cause is an fstab ro entry or a transient with no I/O errors.

sudo mount -o remount,rw /

For a specific partition, name the target explicitly.

sudo mount -o remount,rw /var

On success, findmnt OPTIONS flips to rw. If remount,rw fails with EROFS or cannot remount ... read-write, that is a sign of an underlying I/O error or corruption — don't retry blindly; move on to fsck/disk diagnosis.

remount,rw over suspected corruption makes it worse. Continuing to write while mounted layers more writes on top of broken metadata and can render it unrecoverable. If you see I/O errors, evacuate important data while still read-only, then repair.

How do you repair a corrupted filesystem? (fsck)

Conclusion: Run fsck only when the filesystem is unmounted. Running fsck on a mounted filesystem worsens the damage. Repair root from a Live USB or rescue mode.

Why you must not fsck a mounted filesystem

fsck rewrites blocks directly. Rewriting a mounted (especially rw) filesystem underneath the kernel desynchronizes it from the page cache and destroys data. It is discouraged even when mounted ro. Always unmount, or boot root from a separate environment.

Non-root partitions

sudo umount /dev/sdb1
sudo fsck -y /dev/sdb1

-y: answer yes automatically (skips a flood of prompts)
-f: force a check even if marked clean
for ext4, this invokes fsck.ext4 (= e2fsck)

The root filesystem

Root cannot be unmounted while running. Repair it one of two ways.

Boot from a Live USB / rescue media → run fsck -y /dev/sda1 with root unmounted
Schedule an automatic fsck on next boot and reboot

# Force fsck on next boot (systemd): pass as a kernel parameter
# fsck.mode=force
# Inspect the mount-count-based schedule
sudo tune2fs -l /dev/sda1 | grep -i 'mount count'

On cloud VMs (e.g. AWS EC2), if root goes ro, the safe path is to detach the EBS volume, attach it to another instance, and run fsck there. Check the serial console log (the dmesg equivalent) too.

After repair, verify you can mount and write.

sudo mount /dev/sdb1 /mnt && touch /mnt/.write-test && rm /mnt/.write-test

When should you suspect disk failure?

Conclusion: If dmesg shows I/O error or sector numbers, physical failure is likely. Check health with smartctl, and if the disk is degrading, prioritize data evacuation over fsck.

If you observed hardware I/O errors in dmesg, check the disk's health before repairing anything.

sudo smartctl -a /dev/sda | grep -iE 'health|reallocated|pending|uncorrect'

SMART overall-health self-assessment test result: FAILED!
  5 Reallocated_Sector_Ct   0x0033   100   100   010    -   384
197 Current_Pending_Sector  0x0012   100   100   000    -   16

FAILED, or rising Reallocated_Sector_Ct / Current_Pending_Sector → physical degradation; fsck is only a stopgap
At this stage any write (including fsck's repair writes) can be the final blow. Back up read-only with dd/rsync first.

fsck on a SMART-degraded disk can cause total loss by writing to bad sectors. If the data matters, prefer replacing the disk and restoring from your evacuated copy.

How do you prevent recurrence?

Conclusion: errors=remount-ro is a safety design that surfaces failures instead of hiding them. Keep it, and add SMART monitoring plus free-space/inode monitoring to catch trouble before it goes ro.

Keep errors=remount-ro: the ext4 default. Weakening it to errors=continue hides corruption and widens the damage
Monitor with smartd (smartmontools): get emailed about rising bad-sector counts before it goes ro
Watch capacity and inode exhaustion: write failures from exhaustion are a different problem — see Investigating No space left on device and Handling inode exhaustion
Periodic fsck: set a mount-count-based auto check with tune2fs -c <N>

Shortest flow: ① confirm ro with findmnt → ② identify the cause with dmesg → ③ I/O error present = smartctl + evacuate; absent = remount,rw or fsck (unmounted). Never skipping the cause check is the one thing that prevents disasters.