You try to save a file, touch a config, or write a log, and the shell spits back something like touch: cannot touch 'test.txt': Read-only file system. I know that error is infuriating — especially when you just want to drop a file somewhere and move on with your day.
Here's the short version: the kernel remounted your partition read-only because something went wrong at the block layer. It's a safety mechanism, not a bug. Nine times out of ten it's a failing disk, a full disk that threw write errors, or a VirtualBox disk that got detached mid-write. Find the trigger, and the fix is usually quick.
Work through these in order. Stop when your writes start working again.
Step 1: The 30-Second Fix — Remount Read-Write
If the underlying disk is healthy and you just need to get back to work, remount the filesystem as read-write:
sudo mount -o remount,rw /
Replace / with the mount point you're actually fighting with. Common candidates:
sudo mount -o remount,rw /home— if /home is its own partitionsudo mount -o remount,rw /var— often separate on serverssudo mount -o remount,rw /mnt/usb— for external drives
If it works and stays working, great. If the filesystem flips back to read-only within a minute or two, the kernel is remounting it again because of an ongoing error. Don't keep remounting. Move to Step 2.
One caveat: if you're inside a Docker container and hit this, you can't fix it from inside. The container's filesystem layer is read-only on purpose. Restart the container, or check the host's disk. Remounting inside the container won't help.
Step 2: The 5-Minute Fix — Read the Kernel Log and Fix the Trigger
The kernel always tells you why it remounted. Check the ring buffer:
dmesg | tail -50
You're looking for lines that mention your block device (sda, nvme0n1, vda) with words like:
I/O errorEXT4-fs errorremounting filesystem read-onlyblk_update_request: I/O error
Also check the persistent log, which survives reboots:
journalctl -k -p err --since "1 hour ago"
Match the pattern to the cause:
| Log signature | Likely cause | Fix |
|---|---|---|
I/O error, dev sda | Failing disk, loose SATA cable, bad USB enclosure | Reseat cables, test with smartctl, replace drive |
EXT4-fs error ... in ext4_* | Filesystem corruption | Run fsck (Step 3) |
Buffer I/O error on dev sdb with USB drive | Dirty bit set after unsafe unplug | See USB-specific note below |
blk_update_request on vda | VirtualBox/VMware disk detached mid-write | Shut down the VM cleanly, check host disk status |
USB drives specifically: after an unclean unplug, many USB sticks and external HDDs set a "dirty bit" that the kernel honors by mounting read-only. The fix is to cleanly unmount, unplug for 10 seconds, and plug back in. If that doesn't clear it, run:
sudo umount /dev/sdb1
sudo fsck.vfat -a /dev/sdb1 # for FAT32
# or
sudo fsck.ext4 -p /dev/sdb1 # for ext4
You can't fsck a mounted filesystem. Unmount first, or you'll risk making things worse.
Quick SMART check
If you suspect the disk itself, ask it directly. On a SATA or NVMe drive:
sudo smartctl -a /dev/sda | grep -E "Reallocated|Pending|Uncorrectable"
Any non-zero value on Reallocated_Sector_Ct or Current_Pending_Sector means the drive is dying. Back up now, then replace it. No remount trick will save a disk that's actively failing.
Step 3: The 15-Minute Fix — Run fsck from a Rescue Environment
If you can't unmount the root filesystem while the system's running (and you usually can't), you need to boot into recovery mode or a live USB. This is the case when the read-only remount is caused by filesystem corruption rather than a failing disk.
- Reboot and hold Shift (Ubuntu/Debian) or press Esc early (Fedora/RHEL) to get the GRUB menu.
- Pick Advanced options → a kernel entry ending in (recovery mode).
- Choose fsck from the recovery menu. It'll run automatically on the root partition.
Or, from a live USB, identify the partition and run fsck manually:
lsblk -f
sudo fsck -fy /dev/sda2
For XFS (common on RHEL/CentOS 7+, and on Amazon Linux), fsck.xfs is a no-op. Use the XFS-specific tool instead:
sudo xfs_repair /dev/sda2
The -y flag on fsck.ext4 auto-answers yes to repairs. It can lose data — that's why you back up before running it. If the drive is already unreadable, you probably had no backup anyway, and fsck is your only shot.
If it's btrfs
btrfs handles this differently. Mount read-only explicitly first, then repair:
sudo mount -o ro /dev/sda2 /mnt
sudo btrfs check --repair /dev/sda2
Fair warning: btrfs check --repair has a reputation for doing more harm than good on badly damaged filesystems. If you have irreplaceable data, talk to a recovery specialist before running it.
When none of this works
If the filesystem remounts read-only again within seconds of your fix, and SMART shows reallocated sectors climbing, the disk is done. Stop trying to salvage it in place. Clone it with ddrescue to a healthy drive, then work from the clone:
sudo ddrescue -d -r3 /dev/sda /dev/sdb /root/rescue.log
Every minute you keep writing to a failing disk reduces what you can recover. The 30-second remount is for healthy filesystems. Once SMART turns ugly, the only move is to get your data off.
One last thing people miss: if this is a VM and the host's storage backend filled up, the guest sees the same symptom. Check the host's free space before you tear apart the guest filesystem.