If your VPS suddenly shows a Read-only file system error when you try to create, edit, or delete files, Linux has stopped allowing write operations on the affected filesystem.
This can cause websites to stop updating, applications to fail when saving data, databases to encounter write errors, and services to stop creating logs or temporary files.
A read-only filesystem is not the same as a normal file-permission problem. Linux may mount a filesystem as read-only because of filesystem errors, storage I/O problems, an explicit read-only mount configuration, or other conditions that require investigation.
This guide explains how to identify a read-only file system on a VPS, determine the likely cause, safely restore write access when appropriate, and verify that the underlying problem has been addressed.
What Does a Read-Only File System Mean?
A Linux filesystem can be mounted with either read-write (rw) or read-only (ro) access.
When a filesystem is mounted as read-only, users and applications can generally read existing files but cannot modify them.
For example:
touch test.txt
may return:
touch: cannot touch ‘test.txt’: Read-only file system
You may also encounter errors such as:
mkdir: cannot create directory: Read-only file system
or applications reporting that they cannot write to files.
This is different from:
Permission denied
A permission error is normally related to file ownership or access permissions. A read-only filesystem means the filesystem itself is not currently accepting write operations.
Signs Your VPS File System Is Read-Only
Common symptoms include:
- touch, mkdir, or similar commands fail with Read-only file system.
- Websites cannot update files or upload content.
- Applications cannot create temporary files.
- Services cannot write logs, PID files, or other runtime data.
- Databases may fail when attempting write operations.
- SSH may continue working even though many write operations fail.
- The problem may return after a reboot if the underlying cause has not been resolved.
Before attempting a repair, confirm that the filesystem is actually mounted read-only. A full disk or a permissions problem can produce different errors and requires a different solution.
What Causes a VPS File System to Become Read-Only?
A read-only filesystem is a symptom rather than a single type of failure. The correct solution depends on why the filesystem entered the ro state.
1. File System Errors or Corruption
Filesystem inconsistencies are an important cause of read-only remounts.
For filesystems such as ext4, the kernel can respond to certain filesystem errors by remounting the filesystem read-only to help prevent further damage.
These problems can occur after events such as:
- unexpected shutdowns
- forced VPS resets
- interrupted storage operations
- filesystem corruption
If kernel logs report filesystem errors, simply forcing the filesystem back to read-write may not resolve the underlying problem.
2. Disk or Storage I/O Errors
Persistent storage I/O errors can also cause serious filesystem problems.
You may see messages in the kernel log containing terms such as:
I/O error
or:
Buffer I/O error
In a VPS environment, the problem may involve the virtual disk, the host storage system, or another part of the underlying infrastructure.
If I/O errors continue to appear, contact your VPS provider rather than repeatedly remounting the filesystem.
3. Unclean Shutdown or Forced Reset
An unexpected shutdown does not automatically mean a filesystem will become read-only, but an unclean shutdown can leave filesystem inconsistencies that require recovery.
If the VPS was recently force-stopped, reset, or unexpectedly rebooted, check the kernel and system logs for filesystem errors before assuming the problem is simply a mount configuration issue.
4. Read-Only Mount Configuration
A filesystem can also be intentionally mounted with the ro option.
For example, a mount configuration may specify read-only access, or an administrator may have mounted a filesystem this way for maintenance or investigation.
Check the actual mount options before changing configuration files.
5. Full Disk or Inode Exhaustion
A filesystem reaching 100% capacity can cause applications to fail when they try to create or extend files.
For example:
No space left on device
is normally a space-exhaustion error, not the same as:
Read-only file system
However, disk or inode exhaustion can complicate troubleshooting and should always be checked when applications suddenly stop writing.
Use:
df -h
to check disk capacity and:
df -i
to check inode usage.
Do not assume that freeing disk space alone will fix a filesystem that is genuinely mounted ro.
How to Diagnose a Read-Only File System on VPS
Before applying a fix, determine which filesystem is affected and why.
Step 1: Check the Mount Status
Start by checking the filesystem and its mount options:
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
For the root filesystem specifically:
findmnt /
Look for:
ro
in the mount options.
For example:
TARGET SOURCE FSTYPE OPTIONS
/ /dev/vda1 ext4 ro,relatime
Here, ro indicates that the root filesystem is mounted read-only.
A writable filesystem would normally show rw.
You can also use:
mount | grep ‘ / ‘
but findmnt generally provides a clearer view of the mount configuration.
Step 2: Check Kernel Logs
Next, investigate why the filesystem became read-only.
Run:
dmesg -T | tail -100
On systems where kernel messages are available through systemd’s journal, you can also use:
journalctl -k -n 100
Look for messages related to:
- filesystem errors
- ext4 or another filesystem reporting errors
- remounting as read-only
- I/O errors
- storage errors
- journal errors
For example, a message indicating that a filesystem was remounted read-only is much more significant than simply seeing an application fail to write a file.
Step 3: Check Disk Space
Run:
df -h
Look for filesystems approaching or reaching 100% usage.
If the filesystem is full, identify and safely remove unnecessary data before assuming that filesystem corruption is involved.
For detailed disk-space troubleshooting, link to your VPS Disk Space Cleanup Guide rather than turning this article into a separate disk-management tutorial.
Step 4: Check Inode Usage
A filesystem can have free disk space while running out of available inodes.
Check with:
df -i
If the affected filesystem is at 100% inode usage, applications may be unable to create new files even though df -h shows available storage.
Again, this is different from an actual ro mount and should be treated as a separate capacity problem.
How to Fix a Read-Only File System on a VPS
Once you know the filesystem is mounted read-only, choose the solution based on the evidence from your diagnosis.
Step 1: Try a Read-Write Remount When Appropriate
If there are no indications of filesystem corruption or persistent storage errors and the filesystem was temporarily mounted read-only, you can attempt a remount:
mount -o remount,rw /
For a different mount point, replace / with the affected mount point.
For example:
mount -o remount,rw /var
If the command succeeds, confirm the new mount state:
findmnt /
Look for:
rw
in the mount options.
Then test writing:
touch /tmp/vps-write-test
If successful, remove the test file:
rm /tmp/vps-write-test
Important: A Successful Remount Does Not Prove the Problem Is Fixed
If the filesystem previously became read-only because of filesystem or storage errors, a remount may only restore temporary write access.
Always review the kernel logs.
If errors continue, investigate the underlying cause instead of repeatedly running the remount command.
Step 2: If Remounting Fails, Investigate the Errors
If:
mount -o remount,rw /
fails, do not repeatedly force the filesystem back into read-write mode.
Return to the diagnostic information:
dmesg -T | tail -100
and:
journalctl -k -n 100
If the logs show filesystem corruption or I/O errors, the next step may require an offline filesystem check.
Step 3: Repair the File System With fsck When Required
If filesystem corruption is suspected, fsck may be required to check and repair the filesystem.
Do not run filesystem repair commands blindly against a mounted, active filesystem.
For a VPS root filesystem, the safer approach is normally to use your provider’s rescue or recovery environment so the root filesystem can be checked while it is not actively being used.
First identify the filesystem and device:
lsblk -f
You may see a configuration such as:
NAME FSTYPE MOUNTPOINT
vda
└─vda1 ext4 /
The actual device name will vary between VPS configurations. It could be a virtual disk such as /dev/vda1, an NVMe partition, or another device.
After the correct device has been identified and the filesystem is safely unmounted, run the appropriate filesystem-check command for that filesystem.
For an ext4 filesystem, for example:
fsck.ext4 /dev/vda1
Do not copy /dev/vda1 from this example unless lsblk -f confirms that it is the correct device on your VPS.
Also avoid automatically accepting every repair without understanding the situation. Filesystem repair can modify filesystem metadata, so it should be approached carefully—particularly when important production data is involved.
If you are unsure, use the VPS provider’s recovery tools or contact technical support before performing filesystem repair.
Step 4: Free Disk Space if the Filesystem Is Full
If your diagnosis shows that the filesystem is genuinely out of space or inodes, address that problem separately.
Start with:
df -h
and:
df -i
Identify unnecessary logs, temporary files, backups, or other data that can safely be removed.
Do not delete system files simply to create free space. If you need a complete process for finding what is consuming storage, use the VPS Disk Space Cleanup Guide.
Step 5: Investigate Persistent Storage Problems
If the filesystem repeatedly becomes read-only after appropriate filesystem repair and capacity checks, investigate the storage layer.
Persistent kernel messages containing I/O errors are particularly important.
At this point, the problem may involve infrastructure outside the VPS operating system. Your hosting provider may need to investigate the virtual disk or underlying storage environment.
For a production VPS, provide support with relevant information such as:
- when the issue started
- whether the VPS was recently rebooted or reset
- affected mount point
- filesystem type
- relevant kernel log messages
- whether the problem returns after repair
This is much more useful than simply reporting that “the disk is read-only.”
What Not to Do When a VPS File System Is Read-Only
A few troubleshooting mistakes can make the situation worse.
Do Not Treat It Like a Permission Problem
Commands such as:
chmod
and:
chown
manage file permissions and ownership.
They do not turn a filesystem from ro into rw.
Do Not Repeatedly Force a Remount
A successful:
mount -o remount,rw /
does not repair filesystem corruption or an underlying storage problem.
If the filesystem keeps returning to ro, investigate why.
Do Not Run fsck on an Active Root Filesystem
Running filesystem repair against a mounted and actively used filesystem can cause additional problems.
Use a suitable rescue or recovery environment for the root filesystem.
Do Not Assume /dev/sda1 Is Your VPS Root Disk
VPS storage devices vary.
Use:
lsblk -f
to identify the actual device instead of copying a device name from an example.
Do Not Reboot Before Collecting Useful Diagnostics Unless Necessary
A reboot may temporarily change the filesystem state, but it does not necessarily solve the underlying problem.
If the VPS is still accessible, collect mount information and kernel logs first.
How to Verify the Fix
Do not consider the issue resolved simply because the error disappears once.
After performing the appropriate fix:
1. Confirm the filesystem is writable
findmnt /
Verify that the mount options show:
rw
2. Test a write operation
touch /tmp/vps-write-test
Then:
rm /tmp/vps-write-test
3. Check for new filesystem errors
dmesg -T | tail -50
or:
journalctl -k -n 50
Look for new filesystem or I/O errors.
4. Check affected services
If the problem previously prevented applications from writing data, restart only the affected services when appropriate and verify that they can operate normally.
For example, check whether your web server, database, or application can once again create the files it needs.
If the filesystem becomes read-only again during this verification process, return to the diagnostic stage instead of repeatedly remounting it.
How to Prevent Read-Only File System Problems
There is no way to eliminate every filesystem or storage failure, but good VPS administration can reduce the impact.
Maintain Reliable Backups
Backups protect you when filesystem corruption or storage failure results in data loss.
Do not assume that a backup is usable simply because it completed successfully. Periodically verify that important backups can actually be restored.
See the VPS Backup Verification Guide for a dedicated approach to backup testing.
Monitor Disk and Inode Usage
Regularly check:
df -h
and:
df -i
Monitoring helps you identify capacity problems before applications begin failing.
Monitor VPS Health
System monitoring can help reveal unusual storage, resource, or service behavior.
For broader monitoring practices, see the VPS Monitoring Guide.
Avoid Unnecessary Forced Resets
If the VPS becomes unresponsive, use the least disruptive recovery method available. Repeated hard resets increase the risk of filesystem inconsistency compared with controlled shutdowns.
Investigate Recurring Errors
If your VPS repeatedly reports filesystem or I/O errors, do not treat each occurrence as an isolated incident.
Recurring read-only remounts should be investigated at both the filesystem and storage levels.
Frequently Asked Questions
Common causes include filesystem errors, storage I/O problems, unclean shutdown-related inconsistencies, or a filesystem that was explicitly mounted with read-only options. Kernel logs can help identify the actual cause.
Run:
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
If the affected filesystem shows ro in its mount options, it is mounted read-only.
Sometimes. If the filesystem is otherwise healthy and the read-only state was temporary, a remount can restore write access. If filesystem or storage errors caused the problem, the underlying issue must also be investigated.
Filesystem checks should be performed carefully. You should normally avoid running repair operations against an actively mounted root filesystem. Use a suitable rescue or recovery environment and confirm the correct device before running filesystem repair.
Check the kernel logs for filesystem and I/O errors, verify disk and inode usage, and investigate the filesystem’s health. If the problem persists after appropriate repair, contact your VPS provider because the underlying storage layer may require investigation.
Conclusion
A read-only file system on a VPS is usually a symptom that requires diagnosis rather than a problem that should simply be bypassed.
Start by confirming the mount state with findmnt, then check kernel logs, disk space, and inode usage. If the filesystem is healthy and was temporarily mounted read-only, a read-write remount may restore access. If the logs indicate filesystem corruption, use an appropriate recovery environment and perform an offline filesystem check.
If persistent I/O errors or repeated read-only remounts continue, investigate the underlying storage rather than repeatedly forcing the filesystem back to rw.
Keeping reliable backups, monitoring storage usage, and investigating recurring filesystem errors can significantly reduce the impact of future VPS incidents.
CreativeON’s VPS resources can help you manage the related areas of VPS backups, monitoring, and server administration without turning this troubleshooting guide into a collection of unrelated topics.
The author
Asher Feroze
I’m Asher Feroze, and I’ve been part of CreativeON for several years, working in various roles including Manager Operations, Business Development Manager, and technical support for our web hosting services. Over time, I’ve gained deep insights into both the business and technical sides of the industry. Now, I use that experience to write informative articles for CreativeON, Gworkspace, and gworkspacepartner.pk, helping readers make smart choices when it comes to web hosting and Google Workspace solutions.