Fix 'Read-only file system' Error in Linux

Understanding the 'Read-only File System' Error

When you attempt to write, modify, or delete files on a Linux system and encounter the dreaded message Read-only file system, the kernel has stepped in to prevent potential data corruption. This error occurs when the filesystem has been mounted in read-only mode, either explicitly by an administrator or automatically by the kernel as a safety measure after detecting filesystem inconsistencies or hardware failures.

This guide walks through the root causes, diagnostic steps, and proven remediation techniques to restore full read-write access to your filesystem.

What Causes the Read-only File System State

The Linux kernel can remount a filesystem as read-only under several circumstances. Understanding the trigger is essential for applying the correct fix:

1. Kernel-initiated Remount Due to Filesystem Errors

When the kernel detects metadata inconsistencies, journal corruption, or I/O errors on the underlying block device, it immediately remounts the affected filesystem as read-only. This is a protective mechanism — continuing writes to a corrupted filesystem could cause irreversible data loss. You'll typically see messages like this in the kernel ring buffer:

[Mon Jan 20 14:22:13 2025] EXT4-fs error (device sda1): ext4_journal_check_start:56: Detected aborted journal
[Mon Jan 20 14:22:13 2025] EXT4-fs (sda1): Remounting filesystem read-only

2. Explicit Read-only Mount

A system administrator may have intentionally mounted the filesystem with the ro option in /etc/fstab or during a manual mount command. This is common for recovery operations, forensic analysis, or protecting sensitive directories.

3. Hardware or Storage Failures

Failing SSD sectors, loose SATA cables, dying USB flash drives, or network interruptions on NFS mounts can cause write operations to fail. When the kernel detects a threshold of failed writes, it remounts the filesystem read-only to preserve existing data.

4. Container or Overlay Filesystem Restrictions

In Docker or Podman containers, the root filesystem is often a layered overlay filesystem where the upper directory may become read-only due to underlying storage issues or incorrect mount propagation settings.

Diagnosing the Problem

Before attempting fixes, you must determine which mount point is affected and why. Systematic diagnosis prevents wasted effort and potential data loss.

Check Current Mount Options

Use the mount command to inspect all mounted filesystems and identify those marked as read-only:

mount | grep -E "\(ro[,\)]"
# or more specifically
findmnt --target /path/to/problem-directory

Look for the (ro) flag in the output. For example:

/dev/sda1 on / type ext4 (ro,relatime,errors=remount-ro)

The presence of errors=remount-ro confirms that the kernel automatically switched to read-only mode due to detected errors.

Inspect Kernel Messages

The dmesg command reveals the sequence of events leading to the remount:

dmesg | grep -i -E "read.only|remount|error|filesystem|journal" | tail -30

For systems using journald, you can also query persistent logs:

journalctl -k | grep -i remount
journalctl -k --since "10 minutes ago" | grep -i filesystem

Check Block Device Health

If the underlying storage is failing, filesystem fixes alone won't solve the problem. Check SMART data for physical disks:

smartctl -a /dev/sda
# or for NVMe drives
nvme smart-log /dev/nvme0

Pay attention to attributes like Reallocated_Sector_Ct, Pending_Sectors, and UDMA_CRC_Error_Count. Non-zero values in these fields indicate hardware degradation.

Test Write Access Directly

Confirm the error is consistent by attempting a simple write operation:

touch /path/to/test_write && echo "Write succeeded" || echo "Read-only confirmed"

Fixing the Read-only File System Error

Once you've diagnosed the root cause, apply the appropriate fix from the methods below. Always back up critical data before running disk repair tools.

Method 1: Remount the Filesystem as Read-Write

If the filesystem was intentionally mounted read-only or if a transient error triggered the remount, you can attempt an immediate remount with write permissions:

sudo mount -o remount,rw /mountpoint

For the root filesystem (/), the command is:

sudo mount -o remount,rw /

If the kernel refuses the remount due to persistent errors, you'll see:

mount: /: cannot remount /dev/sda1 read-write, is write-protected.

In that case, you must address the underlying filesystem corruption before remounting.

Method 2: Run Filesystem Consistency Check (fsck)

This is the primary repair method for ext2/ext3/ext4 filesystems that have been remounted read-only by the kernel. The filesystem must be unmounted or in read-only mode for fsck to safely repair it.

For a non-root filesystem, unmount it first:

sudo umount /dev/sdb1
sudo fsck -y /dev/sdb1

The -y flag automatically answers "yes" to all repair prompts. For more aggressive repair of severe corruption:

sudo fsck -f -y /dev/sdb1

For the root filesystem, you cannot unmount it while the system is running. Instead, force a filesystem check on the next boot:

sudo touch /forcefsck
# or for systemd-based systems
sudo touch /boot/forcefsck
sudo reboot

Alternatively, use fsck on a mounted-yet-read-only root filesystem (less ideal but sometimes necessary in recovery mode):

sudo fsck -n /dev/sda1    # -n for read-only check first
# If serious errors are reported, schedule boot-time repair
sudo tune2fs -c 1 /dev/sda1   # force check on next mount
sudo reboot

Method 3: Boot into Recovery Mode or Use a Live USB

When the root filesystem is corrupted and the system won't boot normally, you need an external environment to run repairs:

1. Reboot and hold Shift (or press Esc) to access the GRUB menu
2. Select Advanced options → Recovery mode
3. Choose root to drop into a root shell with networking
4. Run the filesystem check:

# Identify the root partition
lsblk -f
# Run fsck
fsck -y /dev/sda1
# Remount as read-write
mount -o remount,rw /

If recovery mode isn't available, boot from an Ubuntu Live USB or any Linux rescue image, then run fsck from the live environment against the unmounted internal drive partitions.

Method 4: Fix Hardware and Storage Issues

If dmesg shows persistent I/O errors or smartctl reports failing hardware, the filesystem corruption is a symptom, not the root cause. Take these steps:

• Reseat physical connections: Power off the machine, reseat SATA/SAS cables, and check power connectors
• Replace failing cables: A faulty SATA cable can cause intermittent I/O errors that trigger read-only remounts
• Migrate data off a failing drive: If SMART shows reallocated sectors, clone the drive immediately:

# Clone the failing disk to a new one
sudo ddrescue -f /dev/sda /dev/sdb rescue.log
# Then run fsck on the clone
sudo fsck -y /dev/sdb1

• Check NFS server connectivity: For network mounts, verify the NFS server is reachable and the export is configured correctly

# On the client
showmount -e nfs-server-ip
ping -c 4 nfs-server-ip
# Remount with retry options
sudo mount -o remount,rw,hard,intr,retry=3 /mnt/nfs

Method 5: Address Overlay Filesystem Issues in Containers

If you encounter the error inside a Docker container, the underlying overlay filesystem may have become read-only. Common causes include the host's /var/lib/docker partition filling up or the backing filesystem encountering errors.

On the host, check disk space:

df -h /var/lib/docker

If the partition is full, clean up unused images and volumes:

docker system prune -a --volumes

If the host's filesystem has been remounted read-only, fix it using Method 1 or 2 above, then restart the Docker daemon:

sudo systemctl restart docker

For immediate container troubleshooting, you can sometimes remount the container's overlay upper directory:

# Find the overlay mount point
mount | grep overlay
# Remount the host's backing filesystem as rw first
sudo mount -o remount,rw /var/lib/docker/overlay2/...

Preventing Future Read-only Remounts

Proactive measures reduce the likelihood of encountering this error in production environments:

• Monitor disk health: Set up automated SMART monitoring with tools like smartmontools and smartd to alert you before drives fail
• Use journaled filesystems: ext4, XFS, and Btrfs are more resilient to unexpected shutdowns than ext2
• Enable regular fsck: Configure periodic automatic filesystem checks via tune2fs:

sudo tune2fs -c 30 /dev/sda1   # check every 30 mounts
sudo tune2fs -i 1m /dev/sda1   # check every month

• Add mount options for resilience: In /etc/fstab, use errors=remount-ro explicitly (which is default on ext4) and consider data=journal for critical data at the cost of some performance
• Implement UPS for physical servers: Unexpected power loss is a leading cause of filesystem corruption
• Keep container storage thin: Regularly prune unused Docker/Podman images and volumes to prevent disk exhaustion on overlay backing partitions

Best Practices When Dealing with Read-only Filesystems

When you encounter this error in a production environment, follow these best practices to minimize downtime and data loss:

• Do not immediately reboot: A read-only filesystem still allows you to read data and copy it off. Rebooting a system with a corrupted filesystem may worsen the damage
• Copy critical data first: Use rsync, scp, or tar to extract important files while the filesystem is still readable:

rsync -avz /important/data/ user@backup-server:/backup/

• Check all mount points: The error may affect multiple partitions. Run mount and check each one
• Read logs before clearing them: Once you remount as read-write, log entries from the failure event may be overwritten. Capture dmesg output and journalctl logs beforehand
• Test the fix in a sandbox: If the affected drive is critical, practice the fsck and remount procedure on a non-production clone first
• Document the incident: Record which commands were run, what the kernel logs showed, and how the fix was applied for future reference and post-mortem analysis

Conclusion

The Read-only file system error in Linux is a protective mechanism that prevents data corruption when the kernel detects filesystem inconsistencies or hardware failures. Rather than being a roadblock, it serves as an early warning system. By methodically diagnosing the root cause — whether it's a corrupted journal, a failing SSD, a full Docker overlay partition, or an intentional administrative mount — you can apply the correct fix with confidence. The remount command, fsck repair tools, hardware diagnostics, and container storage management together form a complete toolkit for restoring read-write access and preventing recurrence. Always prioritize data extraction before running repairs, maintain regular SMART monitoring, and schedule periodic filesystem checks to catch issues before they escalate into read-only emergencies.