Docs / Troubleshooting / Fix Read-Only Filesystem Errors on Linux

Fix Read-Only Filesystem Errors on Linux

By Admin · Mar 15, 2026 · Updated Apr 23, 2026 · 311 views · 3 min read

A suddenly read-only filesystem is a serious issue — your server can't write logs, create temp files, or save data. The filesystem usually remounts as read-only when the kernel detects disk errors, preventing further corruption. This guide covers diagnosing and fixing read-only filesystem issues on your VPS.

Identify the Problem

# Check mount status
mount | grep "ro,"
# Look for "ro" (read-only) instead of "rw" (read-write)

# Check dmesg for the cause
dmesg | grep -i "error\|readonly\|read-only\|EXT4-fs\|I/O"
# Common messages:
# "EXT4-fs error: remounting filesystem read-only"
# "Buffer I/O error on device vda1"
# "Aborting journal on device vda1"

# Check filesystem type and status
df -Th
cat /proc/mounts | grep " / "

Causes

  • Disk errors: Bad sectors, failing drive, or controller issues
  • Filesystem corruption: Unexpected shutdown, power loss
  • Disk full: No space for journal — kernel panics and remounts RO
  • Hypervisor issue: VPS storage backend problem
  • fstab misconfiguration: Wrong options or missing errors=remount-ro

Immediate Recovery

# Try remounting as read-write
sudo mount -o remount,rw /

# If that fails, check the specific error
sudo mount -o remount,rw / 2>&1

# If disk full, free space first
# (may need to delete files from rescue mode)
sudo rm -rf /var/log/*.gz
sudo journalctl --vacuum-size=100M
sudo apt clean

# Check disk space
df -h /

Run Filesystem Check

# You CANNOT fsck a mounted filesystem
# Option 1: Boot into rescue/single-user mode
# Option 2: If the VPS provider supports it, boot from rescue ISO

# Unmount the filesystem (if not root)
sudo umount /dev/vda2
sudo fsck -y /dev/vda2

# For root filesystem, use rescue mode:
# 1. Boot into rescue mode (VPS provider console)
# 2. Run fsck on the root partition
fsck -y /dev/vda1

# For XFS filesystems
xfs_repair /dev/vda1
# If that fails:
xfs_repair -L /dev/vda1  # WARNING: clears the log, may lose data

# For ext4
e2fsck -f -y /dev/vda1

Check Disk Health

# Check SMART data (if available on VPS)
sudo smartctl -a /dev/sda
sudo smartctl -H /dev/sda  # Quick health check

# Check for I/O errors
dmesg | grep -c "I/O error"
cat /sys/block/vda/stat  # Check error counters

# If using LVM, check physical volume health
sudo pvs
sudo pvck /dev/vda2

# Check for bad blocks
sudo badblocks -sv /dev/vda1  # WARNING: slow, read-only test

Prevent Future Occurrences

# Configure filesystem error handling
# In /etc/fstab, use errors=continue instead of errors=remount-ro
# (Only if you prefer availability over data safety)
# /dev/vda1 / ext4 errors=continue 0 1

# Set up disk space monitoring
df -h / | awk 'NR==2 {print $5}' | tr -d '%'
# Alert when over 90%

# Enable filesystem journaling if not already
sudo tune2fs -l /dev/vda1 | grep "Filesystem features"
# Should include "has_journal"

# Schedule regular fsck
sudo tune2fs -c 30 /dev/vda1   # fsck after 30 mounts
sudo tune2fs -i 3m /dev/vda1   # fsck after 3 months

Best Practices

  • Check dmesg immediately — it tells you exactly why the filesystem went read-only
  • Don't force-remount without understanding the cause — you might make corruption worse
  • Run fsck from rescue mode for root filesystem issues
  • Monitor disk space — full disks cause filesystem errors
  • Keep backups: Filesystem corruption can mean data loss
  • Contact your VPS provider if you suspect storage backend issues

Was this article helpful?