Read-only file system
Fix "Read-only file system": run mount | grep ' ro', check dmesg for I/O errors, then mount -o remount,rw. Covers fsck, containers and cloud volumes.
touch: cannot touch '/var/log/app.log': Read-only file system
Incident Overview
Fix "Read-only file system": run mount | grep ' ro', check dmesg for I/O errors, then mount -o remount,rw. Covers fsck, containers and cloud volumes.
hard fix·5 min read
By Vishvesh Patel·DevOps Engineer·Updated 21 September 2026
touch: cannot touch '/var/log/app.log': Read-only file system OSError: [Errno 30] Read-only file system EXT4-fs error (device nvme0n1p1): ext4_journal_check_start:83: Detected aborted journal EXT4-fs (nvme0n1p1): Remounting filesystem read-only
Do this first3 steps
Run these in order. Each one tells you what its output means before you change anything.
• Find out whether the kernel remounted it or it was mounted that way
An EXT4-fs error or I/O error before the remount means the kernel protected the filesystem from a failing device. No such message means it was simply mounted read-only, which is a configuration question and much less alarming.
• Check how it is currently mounted
The options list shows ro or rw. Compare against /etc/fstab: a filesystem mounted ro that fstab says should be rw points at a boot-time failure rather than an intentional setting.
• Do not remount rw until you know why it went read-only
Remounting a filesystem that went read-only because of I/O errors invites further corruption. Check device health first, and plan for fsck on an unmounted filesystem if the journal aborted.
Two entirely different situations produce this, and treating them the same is how data gets lost.
The kernel remounted it. Something went wrong, usually I/O errors, and the kernel switched to read-only to prevent further damage. This is a hardware or corruption event.
It was mounted read-only. A container's root filesystem, an ro entry in /etc/fstab, a read-only NFS export, or a failed rw mount at boot. This is configuration.
sudo dmesg -T | grep -iE "remount|I/O error|journal|EXT4-fs error|XFS" | tail -20
Which one is it?
That is the kernel protecting you. Do not just remount read-write.
No such message, and you are looking at configuration:
sudo dmesg -T | grep -iE "remount|I/O error|journal|EXT4-fs error|XFS" | tail -20
Case 1: The kernel remounted it
Work out whether the device is failing before touching anything.
On a cloud instance, also check the provider's console. An EBS volume with an impaired status or an instance with a degraded host shows up there and not in SMART.
If the device is healthy, the filesystem still needs checking, and fsck must run on an unmounted filesystem. Running it on a mounted one causes corruption.
For a non-root filesystem:
For the root filesystem, you cannot unmount it. Either boot from rescue media, or schedule a check at the next boot:
On systemd, fsck.mode=force as a kernel parameter does the same.
Take an image first if the data matters and you have somewhere to put it:
fsck -y answers yes to everything, which can discard data it cannot repair. On anything irreplaceable, run it without -y and read each question.
Once you are confident:
Remounting without investigating is the mistake. If the underlying device is failing, writes resume against failing hardware and the corruption gets worse.
sudo smartctl -H /dev/nvme0n1 sudo smartctl -a /dev/nvme0n1 | grep -iE "reallocated|pending|media_errors|percentage_used" sudo journalctl -k --since "2 hours ago" | grep -i "i/o error"
Case 2: Mounted read-only by configuration
An ro where you expected rw is straightforward. Fix the entry:
If fstab says rw and it is mounted ro, the mount failed at boot and systemd fell back. journalctl -b | grep -i mount shows why.
errors=remount-ro in the mount options is the default for ext4 and is what produced Case 1. It is correct behaviour and should stay. errors=continue writes through errors and makes corruption worse; errors=panic halts the machine.
grep -v '^#' /etc/fstab | column -t
Containers
A read-only root filesystem is a good hardening default. Give the application writable space where it genuinely needs it:
Many images write to /tmp, /var/run or a cache directory, so enabling this usually means adding one or two emptyDir mounts. That is worth doing: it turns an arbitrary-write vulnerability into a much less useful one.
docker run --read-only myapp:1.0
Cloud instances
An EBS volume detached and reattached, or an instance stopped and started while a volume was busy, commonly comes back read-only.
AWS Nitro instances present EBS volumes as NVMe devices with names that do not match the attachment name, so /dev/sdf in the console can be /dev/nvme1n1 on the instance. Use lsblk -f and UUIDs in fstab rather than device names, which change across reboots.
lsblk -f sudo dmesg -T | grep -i nvme
A checklist
Frequently Asked Questions
Why did my filesystem become read-only by itself?
The kernel remounted it to prevent further damage after detecting a problem, almost always I/O errors from the underlying device or a corrupted journal. ext4 mounts with errors=remount-ro by default precisely so that a failing disk causes a visible, safe failure rather than silent corruption spreading through your data. dmesg -T shows the triggering error immediately before the remount line, and that message is the thing to investigate, not the read-only state itself.
Can I just remount it read-write?
Not before you know why it went read-only. If the cause was I/O errors from a failing device, remounting read-write resumes writing to failing hardware and makes the corruption worse. Check device health with smartctl -H, look at the cloud provider's console for a volume or host problem, and run fsck on the unmounted filesystem. Once the device is confirmed healthy and the filesystem is clean, mount -o remount,rw is safe.
How do I run fsck on the root filesystem?
You cannot unmount root while the system is running, and running fsck on a mounted filesystem causes corruption. The two options are to boot from rescue media and check the device from there, or to schedule a check for the next boot with sudo touch /forcefsck followed by a reboot. On systemd, adding fsck.mode=force to the kernel command line achieves the same thing. Either way, take a dd image first if the data matters.
Should I use errors=continue to keep the system running?
No. errors=continue tells the kernel to carry on writing after detecting filesystem errors, which turns a contained problem into progressive corruption across your data. The read-only remount is a safety mechanism, and an application failing to write is a much better outcome than a filesystem quietly becoming inconsistent. If availability during a disk fault matters, the answer is redundancy at the storage layer, not disabling the kernel's protection.
Why is my container's filesystem read-only?
Because it was started with --read-only, or in Kubernetes with readOnlyRootFilesystem: true. This is a deliberate hardening measure and a good default, since it prevents an attacker who achieves code execution from modifying binaries or dropping a persistent payload. Most applications need somewhere writable, typically /tmp, /var/run or a cache directory, so mount a tmpfs or an emptyDir at those specific paths rather than disabling the setting entirely.
Reference and practice
Learn the underlying concept
Other Linux errors
Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.
Get notified about new tutorials and features.
• Roadmaps
• Interview Prep
• Certifications
• Company
© 2026 DevOpsLesson. All rights reserved.
Need to practice this scenario?
Simulate this error condition and practice recovery commands safely in our in-browser terminal.