The Error
You try to write a file or create a directory and get hit with:
touch: cannot touch '/var/log/app.log': Read-only file system
Or a variation like:
mkdir: cannot create directory '/etc/myapp': Read-only file system
bash: /tmp/script.sh: Read-only file system
cp: cannot create regular file '/usr/local/bin/mytool': Read-only file system
The filesystem mounted at that path has been switched to read-only mode — either intentionally, or because the kernel forced it after detecting errors.
Root Cause
Linux remounts a filesystem as read-only in a few main scenarios:
- Disk or filesystem errors — when the kernel hits I/O errors or journal inconsistencies, it flips the filesystem to read-only automatically to prevent data corruption.
- Explicit read-only mount — the filesystem was mounted with the
rooption, either in/etc/fstabor via a manualmountcommand. - Hardware failure — a dying disk, bad SATA/SAS cables, or a degraded RAID array can all trigger this.
- Container or VM restrictions — some Docker and Kubernetes setups intentionally mount the host filesystem read-only.
Pay close attention to the first scenario. A kernel-forced remount isn't just annoying — it's a warning that your disk may be in serious trouble. Blindly remounting read-write without checking the cause first can make data corruption worse.
Step 1: Identify Which Filesystem Is Affected
Find out which device backs the path that's causing the error:
df -h /var/log/app.log
Output example:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 12G 36G 25% /
Now check if that device is mounted read-only:
mount | grep /dev/sda1
The (ro, flag is the giveaway:
/dev/sda1 on / type ext4 (ro,relatime,errors=remount-ro)
Alternatively:
cat /proc/mounts | grep ' / '
Step 2: Check the Kernel Logs for the Reason
Don't jump to fixes yet. First, find out why it went read-only:
dmesg | grep -i 'error\|read-only\|remount\|EXT4\|XFS' | tail -30
Or check the system journal:
journalctl -k --no-pager | grep -i 'remount\|error\|I/O error' | tail -20
Seeing messages like EXT4-fs error, I/O error, or remounting filesystem read-only? That means disk errors triggered this. Run a filesystem check before touching anything else.
Clean logs with no error messages? The filesystem was probably mounted read-only on purpose. Skip ahead to the remount step.
Step 3: Check Disk Health
When dmesg shows I/O errors, pull the disk's SMART data:
sudo apt install smartmontools # Ubuntu/Debian
sudo yum install smartmontools # CentOS/RHEL
sudo smartctl -a /dev/sda
A SMART overall-health self-assessment test result: FAILED is an immediate red flag. But even a passing result can hide trouble — check the attribute table for non-zero values in Reallocated_Sector_Ct, Current_Pending_Sector, or Offline_Uncorrectable. Even 5 reallocated sectors is worth taking seriously.
A failing disk must be replaced. Remounting read-write on dying hardware is a data-loss gamble you don't want to take.
Fix A: Remount the Filesystem Read-Write (Quick Fix)
Disk health looks fine, or you just need temporary write access? Remount it:
sudo mount -o remount,rw /
Swap / with the actual mount point for your path — /var, /home, whatever applies:
sudo mount -o remount,rw /var
Verify it worked:
mount | grep '/var'
# Should show (rw, instead of (ro,
Then test your original command:
touch /var/log/app.log
echo $? # 0 means success
Fix B: Run Filesystem Check (When Disk Errors Are Present)
Kernel-forced remounts require a proper fsck on an unmounted filesystem. For non-root partitions, that's straightforward:
sudo umount /dev/sdb1
sudo fsck -f /dev/sdb1
The root filesystem (/) is trickier — you can't unmount it while the system is running. The cleanest approach is booting from a live USB or rescue mode and running fsck from there:
fsck -y /dev/sda1
The -y flag auto-accepts all fixes. After fsck exits cleanly, reboot and the filesystem should come up read-write.
On older systems without live media, you can schedule a check on next boot:
sudo touch /forcefsck
Fix C: Fix fstab If the Filesystem Was Intentionally Mounted Read-Only
Open /etc/fstab and look for a ro option:
cat /etc/fstab
An entry like this is the culprit:
/dev/sda1 / ext4 ro,errors=remount-ro 0 1
Edit the file and swap ro for rw:
sudo nano /etc/fstab
# Change: ro,errors=remount-ro
# To: rw,errors=remount-ro
Apply the change without rebooting:
sudo mount -o remount,rw /
Always validate fstab before you reboot — a syntax error here can leave your system unbootable:
sudo findmnt --verify
Fix D: Check for Hardware Issues
The filesystem keeps going read-only after remounting? The disk itself is probably the real culprit:
# Scan for bad blocks (slow but thorough)
sudo badblocks -v /dev/sda
# Check SMART error counts directly
sudo smartctl -A /dev/sda | grep -E 'Reallocated|Pending|Uncorrectable'
Any non-zero value in those three columns is a warning sign. A Reallocated_Sector_Ct above 10 usually means the drive is on borrowed time. Back up your data now and start planning a replacement.
Verification
After any fix, confirm the filesystem is actually writable:
# Check mount flags
mount | grep rw
# Write test
touch /var/log/app.log && echo 'write OK' || echo 'still read-only'
# Check for new kernel errors
dmesg | tail -10
If you modified fstab, reboot and verify the mount survives correctly:
sudo reboot
# After reboot:
mount | grep '/dev/sda1'
Prevention
- Enable SMART monitoring:
sudo systemctl enable smartd. It watches disk health in the background and can email you before a drive fails completely. - Alert on I/O errors in
dmesg— pipe output through your log aggregator or set up a cron job that greps forI/O errorand sends a notification. - Keep
errors=remount-roin your ext4 fstab entries. It's the right default — it protects data when things go wrong. Just pair it with monitoring so you actually notice when it triggers. - Put
/var/logon its own partition. That way, root filesystem errors don't kill your logging at the worst possible moment.