🚨 Linux Error Guide: 'Read-only file system' EROFS Remounted Read-Only and Corruption

Overview

A “Read-only file system” error (errno EROFS) means a write was rejected because the filesystem holding the target path is mounted read-only. Either it was mounted ro on purpose, or the kernel flipped it to read-only mid-flight to protect data after detecting an error. Any write fails the same way — touch, log rotation, package installs, a database flush — even though reads keep working.

You will see it from almost any tool that tries to write:

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

The distinction that matters for triage is whether the mount was configured read-only (a ro in /etc/fstab, an exported NFS share, a container’s readonly rootfs) or forced read-only by the kernel after an I/O error or detected corruption. The forced case is the dangerous one — it usually means the underlying disk or filesystem is in trouble, and the kernel left a breadcrumb in dmesg.

Symptoms

• Writes fail with “Read-only file system” while reads of existing files still succeed.
• Services that log or write state crash or wedge; package managers refuse to install.
• The mount that used to be rw now shows ro in mount / findmnt.
• dmesg shows I/O errors followed by a remount-read-only message.

mount | grep ' ro,'

/dev/sda1 on / type ext4 (ro,relatime,errors=remount-ro)

dmesg | grep -i "read-only"

[ 8421.337612] EXT4-fs error (device sda1): ext4_journal_check_start:84: comm rsyslogd: Detected aborted journal
[ 8421.337640] EXT4-fs (sda1): Remounting filesystem read-only

Common Root Causes

1. Kernel remounted the filesystem read-only after I/O errors

ext4 mounted with errors=remount-ro (the common default) flips to read-only the instant it hits a write error or journal abort, to stop corruption from spreading.

dmesg -T | grep -iE "I/O error|aborted journal|Remounting filesystem read-only" | tail

[Tue Jun 23 09:14:02 2026] blk_update_request: I/O error, dev sda, sector 1933312 op 0x1:(WRITE) flags 0x0
[Tue Jun 23 09:14:02 2026] EXT4-fs error (device sda1): ext4_journal_check_start:84: comm jbd2/sda1-8: Detected aborted journal
[Tue Jun 23 09:14:02 2026] EXT4-fs (sda1): Remounting filesystem read-only

The write error came first; the remount is the kernel’s reaction. This points at the device, not the mount config.

2. Filesystem corruption that needs fsck

A damaged journal or metadata can leave the filesystem in a state where the kernel refuses to mount it writable until it is checked and repaired.

sudo dumpe2fs -h /dev/sda1 2>/dev/null | grep -E 'Filesystem state|Mount count'

Filesystem state:         clean with errors
Mount count:              312

clean with errors (or not clean) means the filesystem has recorded errors and needs fsck. The kernel will keep it read-only until it is repaired.

3. A failing disk with SMART errors

Read-only-after-I/O-error is frequently a dying drive. SMART attributes expose reallocated sectors and pending failures before the disk goes fully offline.

sudo smartctl -H -A /dev/sda | grep -E 'overall-health|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'

SMART overall-health self-assessment test result: FAILED!
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always   -   72
197 Current_Pending_Sector   0x0012   100   100   000    Old_age   Always   -   24
198 Offline_Uncorrectable    0x0010   100   100   000    Old_age   Always   -   24

A FAILED! health result with pending/uncorrectable sectors means the disk is the root cause. Plan to replace it; do not just remount rw.

4. The mount is intentionally read-only in /etc/fstab

Nothing is broken — the filesystem was mounted ro by design (a hardened /usr, a read-only /boot/efi, or a leftover maintenance entry).

findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /var
grep -nE '\sro[, ]' /etc/fstab

/dev/sdb1 /var ext4 ro,relatime
12:/dev/sdb1  /var  ext4  ro,relatime  0  2

The ro option in /etc/fstab line 12 is the cause. If writes should be allowed, change it to defaults (or rw) and remount.

5. Degraded RAID, container readonly rootfs, or an NFS export mounted ro

The read-only state can come from a layer above the filesystem: a degraded software RAID array that dropped to read-only, a container started with a readonly root, or an NFS share the server exports ro.

cat /proc/mdstat
findmnt -no FSTYPE,OPTIONS /data        # overlay/nfs/etc.

md0 : active raid1 sdb1[0]
      976630464 blocks super 1.2 [2/1] [U_]
nfs4 ro,relatime,vers=4.2,addr=10.0.0.20

[2/1] [U_] shows a RAID1 array missing a member (degraded), and the /data mount is an NFS share exported ro by the server — either can present as read-only to writers.

6. The backing device went away

If the underlying block device disappears (a yanked USB disk, an unmapped SAN LUN, a detached cloud volume), the filesystem can drop to read-only or start throwing I/O errors immediately.

lsblk
dmesg | grep -iE "rejecting I/O|device offline|failed to read|lost page write" | tail

sda      8:0    0   100G  0 disk
└─sda1   8:1    0   100G  0 part   /
sdb         (no longer listed)
[ 9002.114] blk_update_request: I/O error, dev sdb, sector 0 op 0x1:(WRITE)
[ 9002.118] Buffer I/O error on dev sdb1, logical block 0, lost async page write

sdb has vanished from lsblk while the kernel still logs failed writes against it — the device went away under a live mount.

Diagnostic Workflow

Step 1: Identify which mount is read-only

mount | grep ' ro,'
findmnt -t ext4,xfs,btrfs -o SOURCE,TARGET,FSTYPE,OPTIONS

Pin down the exact device and mountpoint, and confirm ro in the options.

Step 2: Decide configured vs kernel-forced

dmesg -T | grep -iE "I/O error|aborted journal|Remounting filesystem read-only|EROFS" | tail
grep -nE '\sro[, ]' /etc/fstab

A remount message in dmesg means the kernel forced it (hardware/corruption). Only a ro in /etc/fstab and a quiet dmesg means it was configured.

Step 3: Check the disk health and device presence

lsblk
sudo smartctl -H /dev/<disk>
cat /proc/mdstat   # if software RAID is in play

A FAILED! SMART result, a missing device, or a degraded array changes the plan from “remount” to “replace/restore”.

Step 4: Inspect filesystem state and run fsck if needed

sudo dumpe2fs -h /dev/<part> 2>/dev/null | grep 'Filesystem state'
# repair from a state where the FS is NOT mounted rw (rescue mode or unmounted)
sudo umount /dev/<part> 2>/dev/null
sudo fsck -y /dev/<part>

If the filesystem state is not clean, run fsck against the unmounted device. Never run fsck on a mounted, writable filesystem.

Step 5: Remount read-write once the cause is cleared

# only after hardware is healthy and any fsck has completed cleanly
sudo mount -o remount,rw /dev/<part> <mountpoint>
mount | grep <mountpoint>

If the remount fails or the filesystem flips back to ro, the underlying error has not been resolved — return to Step 3.

Example Root Cause Analysis

A web server’s application starts throwing 500s and its log file stops growing. Logging in, a simple write fails:

$ touch /var/lib/app/state.db
touch: cannot touch '/var/lib/app/state.db': Read-only file system

mount shows / is ro, and /etc/fstab lists it as defaults — so it was not configured read-only. Checking dmesg:

dmesg -T | grep -iE "I/O error|Remounting filesystem read-only" | tail -3

[Tue Jun 23 03:51:44 2026] blk_update_request: I/O error, dev sda, sector 4202496 op 0x1:(WRITE)
[Tue Jun 23 03:51:44 2026] EXT4-fs (sda1): Remounting filesystem read-only

The kernel forced the remount after a write I/O error, so this is hardware, not config. Confirming with SMART:

sudo smartctl -H -A /dev/sda | grep -E 'overall-health|Reallocated_Sector_Ct'

SMART overall-health self-assessment test result: FAILED!
  5 Reallocated_Sector_Ct   0x0033   071   071   010    Pre-fail  Always   -   948

The disk has reallocated 948 sectors and reports FAILED!. Remounting rw would only invite more corruption. The correct fix is to drain the node, attach a healthy replacement volume, restore from backup or rsync the still-readable data off the dying disk, then fsck and remount on the new device:

# copy readable data off before the disk dies completely
sudo rsync -aAX --info=progress2 /var/lib/app/ /mnt/newdisk/app/
# after repointing the mount to the healthy device:
sudo fsck -y /dev/sdc1
sudo mount -o remount,rw /

The root cause was a failing drive, surfaced by errors=remount-ro doing exactly its job — protecting the filesystem from a disk that could no longer be trusted with writes.

Prevention Best Practices

• Mount critical ext4 filesystems with errors=remount-ro so a write error stops corruption instead of compounding it.
• Run scheduled SMART self-tests (smartctl -t long) and alert on Reallocated_Sector_Ct and Current_Pending_Sector growth before a disk fails outright.
• Monitor dmesg / the kernel ring buffer for “I/O error” and “Remounting filesystem read-only” so you catch a forced remount the moment it happens.
• Keep RAID health and /proc/mdstat under monitoring; a degraded array is a warning, not a steady state.
• Validate /etc/fstab changes with mount -a in a maintenance window so a stray ro does not strand a service.
• When a read-only mount appears in production, the free incident assistant can correlate the dmesg errors with the likely failing device. See more Linux administration guides.

Quick Command Reference

# Which mount is read-only?
mount | grep ' ro,'
findmnt -t ext4,xfs,btrfs -o SOURCE,TARGET,FSTYPE,OPTIONS

# Configured ro or kernel-forced?
dmesg -T | grep -iE "I/O error|aborted journal|Remounting filesystem read-only|EROFS" | tail
grep -nE '\sro[, ]' /etc/fstab

# Disk and array health
lsblk
sudo smartctl -H -A /dev/<disk>
cat /proc/mdstat

# Filesystem state and repair (device must NOT be mounted rw)
sudo dumpe2fs -h /dev/<part> 2>/dev/null | grep 'Filesystem state'
sudo umount /dev/<part>
sudo fsck -y /dev/<part>

# Remount read-write once the cause is cleared
sudo mount -o remount,rw /dev/<part> <mountpoint>

Conclusion

A “Read-only file system” error is the kernel refusing a write because the mount is read-only — and the critical question is whether that state was chosen or forced. A ro in /etc/fstab with a quiet dmesg is benign config; a “Remounting filesystem read-only” message after I/O errors means hardware or corruption, and remounting rw without fixing the cause only risks more damage. The usual root causes:

1. The kernel remounted the filesystem read-only after write I/O errors.
2. Filesystem corruption that needs fsck before it will mount writable.
3. A failing disk reporting SMART errors and reallocated/pending sectors.
4. The mount is intentionally ro in /etc/fstab.
5. A degraded RAID array, a container’s readonly rootfs, or an NFS share exported ro.
6. The backing block device went away under a live mount.

Always read dmesg first — it tells you whether you are looking at a config typo or a dying disk, and that decides whether you remount or replace.