Linux · critical · Day-to-day operations

"Read-only file system" — the filesystem remounted itself read-only

The kernel hit an I/O or metadata error and remounted the filesystem read-only to stop further damage. This is a protection, not the fault itself.

What you see

Writes fail everywhere, logging stops, services fall over. dmesg shows an EXT4-fs or XFS error followed by a remount.

What is actually wrong

A failing disk or cable, a storage path that dropped (SAN, iSCSI, virtual disk), or genuine filesystem corruption.

Codes and articles

Read-only file systemEROFSerrno 30remounting filesystem read-onlyEXT4-fs error

Fixes (2)

Establish whether the disk is failing before touching the filesystem

Shell as root45 minuteslow riskreversible

Any read-only remount. Do this first — running a repair on a dying disk can finish it off.

Read the kernel messages around the event.

Shell

sudo dmesg -T | grep -iE 'error|i/o|remount|ext4-fs|xfs|reset|medium' | tail -40

Check the drive's own health.
Shell
```
sudo smartctl -a /dev/sda | grep -iE 'result|reallocated|pending|uncorrect|wear|health'
```
Reallocated_Sector_Ct and Current_Pending_Sector climbing are the disk telling you it is dying. Repairing a filesystem on top of that buys hours, not days.
If it is a VM, check the hypervisor and storage path — a datastore that briefly disconnected produces exactly this.
Shell
```
sudo dmesg -T | grep -iE 'sd [0-9]|scsi|iscsi|virtio|path' | tail -30
```
If the disk is failing, take an image now, before repairing anything.
Shell
```
sudo ddrescue -f -n /dev/sda /dev/sdb /root/rescue.map
```
ddrescue copies the good blocks first and comes back for the bad ones, which is the opposite of what dd does and the reason it is the right tool here.
Replace the hardware, then restore.

Confirm it workedSMART reports no growing defect counts and dmesg is clean under load.

If you need to undo itNone — this is diagnostic.

Check and repair the filesystem

Single-user mode or a live USB1 hourhigh risknot reversible

The hardware is sound. Never run a repair on a mounted filesystem — it corrupts what it is trying to fix.

Confirm what is mounted and how.
Shell
```
mount | grep ' / 'findmnt -no OPTIONS /
```
For a non-root filesystem, unmount it and check.
Shell
```
sudo umount /dev/sdb1sudo fsck -f /dev/sdb1
```
For the root filesystem, schedule a check at the next boot instead of trying to do it live.
Shell
```
sudo touch /forcefscksudo reboot
```
Running fsck against a mounted root filesystem is the single fastest way to turn a recoverable problem into an unrecoverable one.
Alternatively boot a live USB and check it from there.
Shell
```
sudo fsck -y /dev/sda2
```
XFS uses a different tool and will not repair a mounted or dirty log.
Shell
```
sudo xfs_repair /dev/sda2
```
If XFS refuses because the log is dirty, mount and unmount it once to replay the log before repairing.
Shell
```
sudo mount /dev/sda2 /mnt && sudo umount /mntsudo xfs_repair /dev/sda2
```
xfs_repair -L discards the log and loses whatever was in it. Replaying it properly first is almost always possible and always preferable.
Remount read-write once clean.
Shell
```
sudo mount -o remount,rw /
```

Confirm it workedThe filesystem mounts read-write and stays that way under load.

Shell

findmnt -no OPTIONS / && touch /root/.wtest && rm /root/.wtest && echo OK

If you need to undo itNone. fsck changes are permanent — which is why the image in the previous fix matters.

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.