A filesystem going read-only is usually the kernel protecting data after I/O errors — or a deliberately read-only mount. Distinguish the two fast: one is a fsck, the other is a config.
EXT4 flips read-only on device errors. dmesg -T | grep -iE 'I/O error|read-only' names the device. This is the serious case: copy data off, then repair/replace.
mount | grep ' ro,' shows RO mounts (recovery environments, containers, VM images). Some boot environments mount root RO until remounted (dracut/initramfs shells).
Cloud VMs can lose a data disk briefly; on return the fs may be RO. Check dmesg around the detach time.
findmnt -no OPTIONS / ; sudo dmesg -T | grep -iE 'I/O error|read-only' | tail -5
sudo mount -o remount,rw / # and fix fstab options (defaults vs ro) so it sticks across boots
sudo umount /dev/sdX1 && sudo fsck -y /dev/sdX1 # NEVER fsck a mounted filesystem
smartctl -a /dev/sdX | grep -iE 'reallocated|pending' # nonzero reallocated sectors = plan the replacement now
fsck on a mounted filesystem can corrupt it — the umount is not optional. Recurring RO flips on cloud disks: check provider disk health events before swapping kernels and configs.
It's data protection: after I/O errors, continuing to write risks corrupting the filesystem beyond fsck's repair. The dmesg log right before the flip tells you what triggered it.
If the cause was I/O errors, no — you'd be writing onto a disk that already failed. Remount-rw is for policy/config cases only. Error cases get: backup → fsck/replace.
Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.
Browse the template store →One-time. Yours to modify. Instant download from the NinjaOps template store.