When everything on a box suddenly fails with Read-only file system (EROFS), it's rarely a permissions problem. The kernel hit I/O or journal errors and remounted the filesystem read-only on purpose — a safety reflex (errors=remount-ro) to stop corruption from spreading.
Read the kernel's story first
Don't just remount and move on — find out why it flipped. The kernel log tells you:
dmesg | grep -iE 'ext4-fs error|remounting|I/O error' # e.g. "EXT4-fs (sda1): Remounting filesystem read-only" mount | grep ' / ' # confirms (ro,...) on the mount
A single transient error is one thing; repeated I/O errors or SMART failures mean the underlying disk is dying and needs replacing, not just remounting.
Recover the mount
If the disk checks out, run a filesystem check and remount read-write:
mount -o remount,rw / # bring it back read-write # if it refuses or errors persist, fsck the device (unmounted / at next boot)
Make it survive reboot
A root mount with fsck pass number 0 in /etc/fstab is never checked at boot, so a dirty filesystem can flip straight back to read-only. Set the pass number for / to 1 (and other mounts to 2) so boot-time fsck can clear the error cleanly.
Practise it
A read-only root is one of the Chaos Engine's nastier incidents — everything fails at once. Build the muscle memory in Linux troubleshooting practice, and see the mount-config side in fixing a failed disk mount (/etc/fstab).