Fix 'Read-only file system' Error in Linux: Complete Troubleshooting Guide

Understanding the 'Read-only File System' Error

When you attempt to write, modify, or delete files on a Linux system, you might encounter the dreaded Read-only file system error. This message appears when the kernel has mounted a filesystem in read-only mode, preventing any write operations. The error typically surfaces during routine commands like touch, mkdir, rm, or when saving files in a text editor. Understanding the root cause is the first step toward a reliable fix.

# Typical error messages you might see
$ touch test.txt
touch: cannot touch 'test.txt': Read-only file system

$ mkdir new_directory
mkdir: cannot create directory 'new_directory': Read-only file system

$ rm existing_file.txt
rm: cannot remove 'existing_file.txt': Read-only file system

What Triggers a Read-only Remount?

The Linux kernel automatically remounts a filesystem as read-only when it detects filesystem corruption, critical I/O errors, or underlying storage failures. This is a protective mechanism designed to prevent further data loss. Common triggers include:

Disk corruption caused by improper shutdowns or power failures
Bad sectors or physical damage on hard drives and SSDs
Failed RAID arrays entering degraded or offline states
Faulty cables or loose SATA/USB connections
Kernel bugs in specific filesystem drivers
Filesystem journal errors that prevent safe writes

Why This Error Matters

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

A read-only filesystem is not merely an inconvenience — it is a symptom of potentially serious underlying problems. Ignoring the error and simply rebooting without investigation can lead to progressive data corruption, permanent file loss, or complete storage failure. In production environments, this error on critical mount points like / (root) or /var can halt services, disrupt logging, and cause application crashes. Understanding the urgency helps you respond with the correct diagnostic and recovery steps.

Critical Mount Points at Risk

/ (root filesystem): A read-only root prevents system updates, user logins, and most daemon operations
/home: Users lose the ability to save documents and configurations
/var: Logging stops, databases may fail, and package management breaks
/tmp: Temporary file operations fail, affecting compilers and scripts

Diagnostic Steps Before Attempting a Fix

Before jumping into recovery, you must determine which filesystem is affected, what caused the remount, and whether the storage hardware is still reliable. Systematic diagnostics prevent wasted effort and protect against further damage.

Step 1: Identify the Affected Mount Point

Run the mount command and look for entries flagged with ro (read-only) in the mount options. Compare the output with your expected mount configuration from /etc/fstab.

# List all mounted filesystems and check for 'ro' flag
$ mount | grep -E '(ro,|,ro |read-only)'

# Example output showing a read-only root filesystem
/dev/sda1 on / type ext4 (ro,relatime,errors=remount-ro)

# More detailed view with findmnt
$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | grep -E 'ro[, ]'

Step 2: Check Kernel Ring Buffer Messages

The kernel logs detailed messages about filesystem errors and remount decisions via dmesg. These messages often reveal the exact error type, affected block device, and inode numbers.

# Examine kernel messages for filesystem errors
$ dmesg | grep -i -E '(read.only|filesystem|error|remount|I/O|journal|ext4|btrfs|xfs)'

# Look for critical buffer I/O errors
$ dmesg | grep -i 'buffer i/o error'

# Check for specific device errors (replace sda1 with your device)
$ dmesg | grep -i sda1

Step 3: Inspect Systemd Journal (if applicable)

On systemd-based distributions, the journal often contains correlated messages from mount units and filesystem check services.

# Query journal for filesystem-related messages
$ journalctl -xe | grep -i -E '(filesystem|read.only|remount|fsck)'

# Check messages from the last boot
$ journalctl -b | grep -i 'read-only'

Step 4: Verify Storage Hardware Health

Use smartctl from the smartmontools package to check the physical health of your storage device. Pay attention to Reallocated_Sector_Ct, Pending_Sectors, and UDMA_CRC_Error_Count.

# Install smartmontools if missing
$ sudo apt install smartmontools   # Debian/Ubuntu
$ sudo dnf install smartmontools   # Fedora/RHEL

# Run a short self-test and view health status
$ sudo smartctl -a /dev/sda

# Key attributes to watch
$ sudo smartctl -a /dev/sda | grep -E '(Reallocated|Pending|CRC|Pre-Fail)'

Fixing the Read-only File System: Practical Solutions

Once diagnostics confirm the affected mount point and reveal the error type, you can proceed with the appropriate fix. The solutions below range from quick remount attempts to deep filesystem repairs. Always back up critical data before running repair tools.

Solution 1: Immediate Manual Remount (Temporary Fix)

If the kernel remounted the filesystem due to a transient error that has since resolved (e.g., a loose cable that was reconnected), you can attempt a manual remount with read-write permissions. This does not repair underlying corruption but restores write access if the filesystem is structurally sound.

# Remount a specific mount point as read-write
$ sudo mount -o remount,rw /

# For a non-root filesystem, specify the mount point
$ sudo mount -o remount,rw /home

# Verify the remount succeeded
$ mount | grep '/home'

If the remount fails with an error like mount: /: cannot remount /dev/sda1 read-write, is write-protected, the kernel has detected persistent corruption and you must proceed to filesystem repair.

Solution 2: Filesystem Consistency Check and Repair (fsck)

The most common and effective fix involves running fsck (File System Consistency Check) on the affected partition. This must be done when the filesystem is unmounted or mounted read-only to prevent data races. For the root filesystem, you typically need to boot into a live USB environment or use init=/bin/bash at boot.

Repairing Non-Root Filesystems

# First, unmount the filesystem (if possible)
$ sudo umount /home

# Run fsck with automatic repair (-a) or user-interactive (-r)
$ sudo fsck -a /dev/sda2

# For XFS filesystems, use xfs_repair instead
$ sudo xfs_repair /dev/sda2

# For Btrfs, use btrfs check
$ sudo btrfs check --repair /dev/sda2

Repairing the Root Filesystem

Since the root filesystem cannot be unmounted while the system is running, use one of these methods:

Method A: Force fsck at Next Boot

# Create a forcefsck file to trigger fsck on next reboot
$ sudo touch /forcefsck

# Or use the systemd-compatible approach
$ sudo touch /var/lib/systemd/force-fsck

# Reboot the system
$ sudo reboot

Method B: Boot into a Live USB and Run fsck

# After booting from a live USB, identify your root partition
$ sudo fdisk -l
$ sudo blkid

# Run fsck on the unmounted root partition
$ sudo fsck -a /dev/sda1

# Mount to verify and chroot if needed
$ sudo mount /dev/sda1 /mnt
$ sudo mount --bind /dev /mnt/dev
$ sudo mount --bind /proc /mnt/proc
$ sudo mount --bind /sys /mnt/sys
$ sudo chroot /mnt

Method C: Use init=/bin/bash for Single-User Recovery

# At the GRUB boot menu, press 'e' to edit the kernel command line
# Add 'init=/bin/bash' to the line starting with 'linux'
# Boot with Ctrl+X or F10

# Once at the root shell, remount root as read-write if possible
# mount -o remount,rw /

# Run fsck from this minimal environment
# fsck -a /dev/sda1

Solution 3: Handling Specific Filesystem Types

Different filesystems require different repair tools and flags. Using the wrong tool can cause further damage.

ext2/ext3/ext4

# Full check with verbose output, automatic repair
$ sudo fsck.ext4 -fvy /dev/sda1

# Force check even if the filesystem appears clean
$ sudo fsck.ext4 -f /dev/sda1

# Specify an alternate superblock if the primary is corrupted
$ sudo fsck.ext4 -b 32768 /dev/sda1

XFS

# Check and repair XFS filesystem (must be unmounted)
$ sudo xfs_repair /dev/sda1

# Repair with verbose output and no modify (dry-run first)
$ sudo xfs_repair -n /dev/sda1

# For severely damaged XFS, use the dangerous flag
$ sudo xfs_repair -L /dev/sda1  # Zeroes the log, use as last resort

Btrfs

# Check Btrfs filesystem without repair
$ sudo btrfs check /dev/sda1

# Repair with caution (backup data first)
$ sudo btrfs check --repair /dev/sda1

# For mounted Btrfs, scrub to detect and correct errors online
$ sudo btrfs scrub start /mnt/data
$ sudo btrfs scrub status /mnt/data

Solution 4: Recover from Superblock Corruption (ext family)

If fsck complains about a bad superblock, ext2/ext3/ext4 filesystems keep backup superblocks at fixed offsets. You can locate and use them.

# Find backup superblock locations
$ sudo mke2fs -n /dev/sda1

# Example output showing backup blocks
# Superblock backups stored on blocks:
#     32768, 98304, 163840, 229376, 294912, 819200, 884736

# Run fsck using a backup superblock
$ sudo fsck.ext4 -b 32768 /dev/sda1

Solution 5: Resolve Hardware-Induced Read-only States

Sometimes the storage device itself enforces a read-only state. SD cards and some SSDs have physical write-protect switches or enter read-only mode when nearing end-of-life.

# Check if the device reports write protection
$ sudo hdparm -r /dev/sdb

# If the device is locked, try removing software write protection
$ sudo hdparm -r0 /dev/sdb

# For mmc/SD cards, check the ro attribute
$ cat /sys/block/mmcblk0/ro
# 1 = read-only, 0 = writable

Solution 6: Handling Loop and Overlay Mounts

Containerized environments and sandboxed applications often use loop devices or overlay filesystems. These can enter read-only states due to upper directory exhaustion.

# List loop devices and their backing files
$ losetup -a

# Check overlay mounts
$ mount | grep overlay

# Remount an overlay with read-write (if upper dir is writable)
$ sudo mount -o remount,rw /path/to/overlay/mount

Best Practices for Prevention and Recovery

Preventing read-only filesystem errors is far better than recovering from them. Implement these practices across your Linux environments to minimize risk.

1. Use Journaling Filesystems

Always prefer journaling filesystems like ext4, XFS, or Btrfs over ext2. The journal allows quick recovery after crashes and reduces corruption risk. Verify your current filesystem type with df -T.

2. Configure Proper Mount Options in fstab

The errors=remount-ro option in /etc/fstab is a double-edged sword — it protects data but can halt operations. Consider adding noatime to reduce write frequency and data=ordered for ext4 safety.

# Example robust fstab entry
# UUID=a1b2c3d4 / ext4 defaults,errors=remount-ro,noatime 0 1
# UUID=e5f6g7h8 /home ext4 defaults,noatime,nodiratime 0 2

3. Regular Storage Health Monitoring

Schedule periodic SMART tests and monitor key attributes. Use tools like smartd (the smartmontools daemon) to send alerts before failures occur.

# Enable smartd monitoring
$ sudo systemctl enable smartd
$ sudo systemctl start smartd

# Configure /etc/smartd.conf with email alerts
# Example: /dev/sda -a -o on -S on -s (S/../.././02|L/../../7/02) -m root@localhost

4. Implement Uninterruptible Power Supplies (UPS)

Sudden power loss is the leading cause of filesystem corruption. A UPS with automatic shutdown capability (nut package, Network UPS Tools) allows clean unmounting before battery exhaustion.

# Install NUT for UPS monitoring
$ sudo apt install nut
$ sudo dnf install nut

# Configure upsmon.conf for automatic shutdown
# /etc/nut/upsmon.conf entries trigger shutdown on low battery

5. Maintain Regular Backups

No repair tool is guaranteed to recover all data. Maintain tested, off-machine backups. Tools like rsync, borgbackup, or restic combined with snapshots provide reliable recovery points.

6. Create a Recovery Toolkit

Keep a live USB with your distribution's latest ISO, the smartmontools package, and filesystem repair utilities pre-installed. Document your partition layout and UUIDs. Store this information separately from the affected machine.

Advanced Troubleshooting Scenarios

Scenario A: Root Filesystem Read-only After Kernel Update

Occasionally, a kernel update introduces regressions in storage drivers. Boot the previous kernel from GRUB, verify the issue disappears, and report the bug to your distribution. While running the older kernel, run fsck to clean up any damage the new kernel may have caused.

Scenario B: LVM Logical Volume Read-only

LVM adds a layer of abstraction. The read-only state may originate from the Physical Volume (PV), Volume Group (VG), or the Logical Volume (LV) itself.

# Check LVM component status
$ sudo pvdisplay
$ sudo vgdisplay
$ sudo lvdisplay

# If a PV is missing or failed, activate the VG partially
$ sudo vgchange -a y --partial my_volume_group

# Run fsck on the LV device path
$ sudo fsck -a /dev/my_volume_group/my_logical_volume

Scenario C: NFS or Network Mounts Going Read-only

Network filesystems like NFS can become read-only if the server revokes write permissions, the network link fails, or the client loses its lease.

# Check NFS mount options
$ mount | grep nfs

# Remount with explicit read-write and hard/intr options
$ sudo mount -o remount,rw,hard,intr server:/export /mnt/nfs

# Check server-side exports for read-only flag
$ showmount -e nfs-server.example.com

Conclusion

The Read-only file system error is a protective response from the Linux kernel that demands careful investigation rather than blind rebooting. By systematically identifying the affected mount point, reading kernel diagnostics, verifying hardware health, and applying the correct filesystem repair tools, you can recover from most situations without data loss. Prevention through journaling filesystems, UPS protection, SMART monitoring, and regular backups transforms this error from a catastrophic event into a manageable alert. Remember that persistent read-only remounts after repair indicate failing hardware — replace the storage device promptly to avoid compounding the damage. With the diagnostic workflow and solutions in this guide, you are equipped to handle read-only filesystem errors across ext4, XFS, Btrfs, and network-mounted filesystems on any Linux distribution.