Why has a Linux filesystem become read-only?
A read-only filesystem can be intentional, inherited from a container image, or a protective response to filesystem or device errors. It is different from a file ownership problem. Inspect the mount and kernel evidence before trying to remount it writable; repeated writes can worsen an underlying storage fault.
Before you start
- An authorised SSH session on the Linux server.
Instructions
1. Inspect the actual mount options
Query the failing path and look for ro among the active options. Ensure you are checking the filesystem used by the application rather than a similarly named directory.
findmnt -T /var -o TARGET,SOURCE,FSTYPE,OPTIONSReplace /var with the affected path. A read-only bind mount or container root may be an intentional deployment control.
2. Review recent storage and filesystem errors
Read the current boot’s kernel context around the failure. Preserve exact error messages and device identifiers for the storage or provider team.
sudo journalctl -k -b -p warning -n 100 --no-pagerLook for I/O, filesystem or device-reset errors. Avoid running a repairing filesystem check on a mounted live filesystem.
Check the result
- The cause is identified as policy, mount configuration or a storage fault, and the recovery procedure matches that filesystem and device stack.
Troubleshooting
- Changing permissions does not help
- Permission bits cannot make a read-only mount writable.
- A remount briefly works and then fails again
- Investigate the recurring underlying error. Do not use repeated forced remounts as a permanent repair.
- An offline check is needed
- Arrange a maintenance and recovery environment according to the filesystem’s supported procedure.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.