VPS Turned Into a Read-Only Filesystem (2026): Troubleshooting read-only file system, fsck, and emergency mode

First check the root partition mount status:

findmnt /
mount | grep ' on / '

If you see something like:

/ rw,relatime,...

that means the root partition is still read-write. In this case, being unable to write files may be due to a full disk, exhausted inodes, directory permissions, quotas, or the application itself.

If you see:

/ ro,relatime,...

Here ro means read-only, and the root partition has been mounted read-only. At this point, don't treat the problem as an ordinary permission error.

Also check space and inodes:

df -h
df -i

If space is full, you can first read: What to Do When the VPS Disk Is Full? Disk Cleanup + Expansion. If there is still space but inodes are used up, read this: VPS Shows Disk Space Available but Cannot Write Files: Inode Exhaustion Troubleshooting.

When the filesystem turns read-only, application logs often only tell you "write failed"; the real cause is in the kernel logs.

dmesg -T | tail -n 100
journalctl -k --since "2 hours ago"

Focus on these keywords:

EXT4-fs error
Buffer I/O error
blk_update_request
I/O error
Remounting filesystem read-only
XFS ... metadata I/O error

If Remounting filesystem read-only appears, it means the kernel detected a filesystem or block device anomaly and proactively remounted it read-only.

If you're not familiar with log troubleshooting, you can first refer to: How to Read VPS Logs: journalctl, systemctl, Nginx, Application Logs.

Many tutorials will directly give you:

sudo mount -o remount,rw /

This command isn't unusable, but it can't be the first step.

If it's just a one-time abnormal mount parameter, remount may restore writes; but if the underlying disk or filesystem has already reported errors, forcing writes may expand the corruption. A more reliable order is:

1. Check whether dmesg / journalctl -k has I/O or filesystem errors.
2. Back up important data that can still be read first.
3. Determine whether you need to enter rescue mode to run fsck.
4. Mount read-write after repair.

Only when the logs show no obvious disk/filesystem errors and you confirm the risk is controllable should you try:

sudo mount -o remount,rw /

If the command fails, note the error and don't run it repeatedly.

Sometimes the read-only state is actually an opportunity: the system temporarily can't write, but it can still read. Get the key data out first.

Prioritize backing up:

• Database dumps or data directories
• /var/www, application upload directories
• /etc/nginx, /etc/systemd/system, application configs
• .env, keys, certificates
• Recent logs and troubleshooting screenshots

If the machine can still connect to the network, you can pull them out with rsync:

rsync -aHAX --numeric-ids /var/www/ user@backup-server:/backup/vps-www/

If the network is unstable, first compress key directories to another properly mounted data disk, or use panel snapshots/cloud disk snapshots. For backup strategies, you can refer to: VPS Automatic Backup Solutions.

A very common cause of entering emergency mode after reboot is a misconfigured /etc/fstab:

• A non-existent UUID was written.
• A cloud disk that has already been deleted is mounted.
• The filesystem type is wrong.
• A network disk or object storage mount failed, but there is no nofail.
• After manually adding a data disk, the boot order is unstable.

View fstab:

cat /etc/fstab
blkid
lsblk -f

If you find that the UUID of a non-root partition doesn't exist, you can temporarily comment out that line and then reboot to verify.

For non-critical data disks, it's recommended to add nofail to avoid an additional disk mount failure blocking the entire VPS into emergency mode:

UUID=xxxx /data ext4 defaults,nofail 0 2

Don't casually add nofail to the root partition. If the root partition can't be mounted, it should stop and be handled anyway.

If the root partition has already reported ext4 errors, fsck is usually needed. But running fsck directly on a mounted root partition is dangerous.

A more reliable approach:

1. Enter the rescue mode / recovery mode provided by your VPS provider.
2. Find the root partition device name.
3. Confirm it is not mounted.
4. Run fsck.

View partitions:

lsblk -f
blkid

Assuming the root partition is /dev/vda1:

sudo fsck -f /dev/vda1

If it's XFS, you can't use the ext4 fsck repair method:

sudo xfs_repair /dev/vda1

Note: In different providers' rescue environments, the device name may change from /dev/vda1 to /dev/sda1 or /dev/nvme0n1p1. Always rely on lsblk -f, and don't copy someone else's device name.

If the logs contain a large number of I/O errors, for example:

Buffer I/O error on dev vda
blk_update_request: I/O error

This isn't necessarily a misconfiguration in your system; it could also be:

• Underlying cloud disk anomaly
• Host machine storage jitter
• VPS node failure
• Overselling causing prolonged I/O anomalies
• Cloud disk migrated or rate-limited by the provider

In this case, keep the logs and open a ticket as soon as possible. In the ticket, don't just write "the machine is broken"; it's best to include:

dmesg -T | tail -n 100
journalctl -k --since "6 hours ago"
lsblk -f
findmnt /

If you suspect neighbor resource contention or disk jitter, you can compare with: How to Judge VPS Overselling: CPU Steal, Disk Jitter, Neighbors Grabbing Resources.

After fsck or xfs_repair completes, mount and check first:

sudo mount /dev/vda1 /mnt
ls /mnt

Focus on:

• Whether /mnt/lost+found has a large number of files
• Whether the database directory is complete
• Whether the application upload directory is complete
• Whether /etc/fstab has been corrected
• Whether there are still new I/O errors in the logs

If it can start normally, don't switch traffic back immediately either. Check the services first:

systemctl --failed
journalctl -p err -b

Be especially cautious with database-type services. If services like MySQL, PostgreSQL, and Redis were forcibly interrupted during the filesystem anomaly, they may also need their own data consistency checks.

In the following situations, it's not recommended to keep forcing repairs on the original disk:

• dmesg continuously shows I/O errors.
• It quickly turns read-only again after fsck repair.
• Key database files are corrupted and there is no reliable verification.
• The provider confirms a storage node anomaly.
• This machine has already entered emergency mode multiple times.

At this point, a more reliable route is:

1. Restore from snapshot or backup to a new VPS.
2. Verify business data.
3. Switch DNS or reverse proxy entry.
4. Keep the old machine in read-only state to retrieve additional data.

For migration ideas, you can refer to: VPS Migration Guide: How to Minimize Downtime When Changing Providers/Data Centers.

When encountering read-only file system or emergency mode, handle in this order:

1. findmnt / check whether the root partition is ro.
2. df -h and df -i to rule out full space and inode exhaustion.
3. dmesg -T / journalctl -k to find filesystem and I/O errors.
4. Back up key directories first when data is readable.
5. Check whether /etc/fstab, blkid, lsblk -f match.
6. Don't run fsck directly on a mounted root partition.
7. Enter rescue mode and run fsck or xfs_repair on the unmounted partition.
8. After repair, check systemctl --failed and the error logs.
9. If I/O errors persist, prioritize migration; don't keep gambling on the original disk.

A VPS turning into a read-only filesystem is not an ordinary "insufficient permissions" issue. It's often the system protecting data: either the disk/filesystem has failed, the boot mount configuration is inconsistent, or the underlying cloud disk has become unstable.

The correct handling order is: look at logs and mount status first, back up first if readable, then fix fstab or enter rescue mode to do a filesystem check. Recovery is good, but as long as I/O errors keep recurring, don't keep betting your business on the original disk; migrate to a new machine as soon as possible.