Fix: touch: cannot touch 'file': Read-only file system

A Read-only file system error means the write failed because the mount does not allow writes. On a healthy machine that can be deliberate configuration, but when it appears suddenly on a system that was writing fine an hour ago, the usual story is that the kernel detected an I/O error or filesystem corruption and remounted the volume read-only to protect your data. Databases, logs, and uploads all start failing at once. Resist the urge to remount immediately: the reason it went read-only is the actual incident.

touch: cannot touch 'file': Read-only file system

What this error means

Every mount has a read-write or read-only state. The EROFS error simply reports that state, but how the mount got there matters. Filesystems like ext4 carry an error policy (errors=remount-ro is a common default) telling the kernel what to do when metadata operations fail or the journal aborts: flip to read-only so no further writes can compound the damage. SSDs and RAID controllers can also force their whole device read-only when they run out of spare cells or lose a member. So the message is one symptom with three distinct stories: deliberate configuration, a filesystem that demoted itself after errors, or dying hardware, and dmesg tells you which one you have.

Common causes

• The kernel remounted the filesystem read-only after an I/O error or journal abort (errors=remount-ro behavior on ext4).
• Failing storage: a disk with bad sectors, an SSD at end of life switching to read-only mode, or a degraded RAID or SAN path.
• A cloud block volume detached, resized, or briefly unreachable, aborting the journal mid-write.
• Deliberate configuration: ro in /etc/fstab, a read-only container root filesystem, or a snapshot mounted read-only.
• An unclean shutdown leaving the filesystem flagged dirty, mounted read-only at boot pending a check.

How to fix it

STABILIZE first. Identify which mount is read-only and stop write-heavy services that are error-looping against it, especially databases, so they fail cleanly instead of thrashing.

grep ' ro,' /proc/mounts
findmnt -o TARGET,SOURCE,OPTIONS /var
systemctl stop myapp

1. DIAGNOSE why it is read-only. Read the kernel log for the moment things changed; I/O errors or an ext4 journal abort here mean corruption or hardware, not configuration.

dmesg -T | grep -iE 'error|ext4|xfs|remount|i/o' | tail -30

2. Check the disk’s own health before trusting it with repairs or new writes.

smartctl -H /dev/sda
smartctl -A /dev/sda | grep -iE 'realloc|pending|wear'

3. If dmesg shows filesystem errors, repair the filesystem while it is not mounted read-write. For the root filesystem, schedule a check at reboot or use a rescue environment; never fsck a mounted read-write volume.

umount /data
fsck -f /dev/sdb1
mount /data

4. FIX according to the story. If the disk is healthy and the filesystem checks clean (for example after a transient SAN blip), remount read-write:

mount -o remount,rw /data

If SMART shows reallocated or pending sectors, or the SSD reports itself worn out, do not fight it: the device is failing. Restore write service by moving the workload to a healthy volume and restore data from backups where the repair lost files.

5. If the mount was configured read-only, fix the source: the ro option in /etc/fstab, or for containers, keep readOnlyRootFilesystem: true and give the app writable volumes where it needs them:

securityContext:
  readOnlyRootFilesystem: true
volumeMounts:
  - name: tmp
    mountPath: /tmp
volumes:
  - name: tmp
    emptyDir: {}

How to prevent it

• Monitor SMART attributes and cloud volume health, and alert on the first kernel I/O error rather than the eventual remount.
• Alert on any mount unexpectedly in ro state, which is a one-line check that catches this whole class early.
• Keep backups current and restore-tested, since filesystem repair after real corruption is never guaranteed.
• Use redundant storage (RAID, replicated volumes) for anything whose downtime is expensive.
• Ensure clean shutdowns and journaling defaults on every data volume, and document which mounts are intentionally read-only.

When to call a senior engineer

Call for help when the filesystem keeps demoting to read-only after repairs, when fsck reports damage on a volume holding a production database, or when you are staring at a failing disk and unsure what can still be copied off safely. Erzon engineers can triage storage failures in the right order, recover data before the hardware finishes dying, and rebuild the volume layout and monitoring so the next disk failure is an event, not an outage.