You're working away, and suddenly every write to /home or /var fails with read-only file system. Even touch test gives you Read-only file system. This usually shows up right after a power outage, a kernel panic, or a hard reset. The system boots, mounts your partitions, and then quietly locks them down. No scary messages at boot, just a silent switch to read-only.
What's actually happening here is that the kernel detected an error during the mount or while the filesystem was in use. For ext4 and friends, the default behavior in many distros is to remount the filesystem read-only when the journaling layer hits something it can't handle. The idea is to stop further writes that might make corruption worse. It's a safety mechanism, not a hardware failure.
The root cause is almost always an unclean shutdown. The journal didn't get a chance to replay cleanly, so the filesystem is in an inconsistent state. The kernel decides it's safer to deny writes than to risk scribbling over half-recovered metadata. Sometimes it's a genuine hardware issue like a failing disk, but that's less common than you'd think.
The fix is straightforward: check the filesystem, fix any errors, and remount it read-write. But don't just blindly run mount -o remount,rw / — that can make things worse if there's real corruption. Here's the order that works.
Step 1: Identify which filesystem is read-only
Run mount | grep ro to list all mounts that are currently read-only. You'll see something like:
/dev/sda2 on / type ext4 (ro,relatime,errors=remount-ro)
Note the device (here /dev/sda2) and the mount point (/). If it's your root partition, you'll need to boot from a live USB or use a rescue mode to run fsck. If it's a non-root partition like /home, you can unmount it and check it from the running system.
Step 2: Unmount the read-only filesystem
If the mount point isn't your root partition, unmount it:
sudo umount /home
If you get target is busy, find what's using it with lsof +f -- /home or fuser -vm /home, kill those processes, then unmount again. Don't force it with umount -l unless you really have no choice — that can leave half-written files.
Step 3: Run fsck to check and repair
Now run a filesystem check. For ext4, the command is:
sudo fsck.ext4 -f /dev/sda2
The -f forces a check even if the filesystem looks clean. You'll likely see messages about the journal being recovered, or orphaned inodes being cleaned up. Answer y to any prompts if you're confident, but if it's asking about something you don't understand, say no and investigate. Most of the time, letting it fix journal errors is safe.
If you're on an XFS filesystem, use xfs_repair instead. XFS doesn't have a separate journal check like ext4, but xfs_repair -n does a dry run first.
Step 4: Remount read-write
After fsck finishes cleanly, mount it back:
sudo mount /home
Or, if the filesystem was never unmounted, you can remount in place:
sudo mount -o remount,rw /home
For your root partition, you'd do this from a live environment. Boot from a USB stick, mount your root partition manually, run fsck, then reboot normally.
Step 5: Check the kernel logs for the real cause
Once you're back to read-write, look at the logs:
dmesg | tail -50
Look for lines like EXT4-fs error (device sda2): or Remounting filesystem read-only. The message right before that tells you what went wrong. If it mentions I/O errors, you might have a dying disk. If it's just journal recovery issues, you're probably fine.
If it still fails after this
If the filesystem goes read-only again after you remount, you're dealing with a recurring problem. First, check for hardware faults with sudo smartctl -a /dev/sda — look at Reallocated_Sector_Ct and Current_Pending_Sector. If those are climbing, back up your data and replace the disk.
Second, look at the mount options in /etc/fstab. Some distros set errors=remount-ro by default. If you're on a system where uptime matters more than data safety, you could change it to errors=panic (but that's a terrible idea for a desktop). I'd leave it as-is unless you have a solid backup strategy.
Third, consider that the filesystem might be legitimately damaged beyond what fsck can fix. In that case, restore from backup. This is why I nag everyone about backups — a read-only filesystem is often the first sign that something's wrong, and it's way cheaper to fix when you have a good backup.