### [VPS报Read-only file system怎么办？先保留现场，别急着强制重新挂载](https://www.jiyueip.com/article/13296)

**Published:** 2026-07-29T16:51:00

**Author:** 斑斓助理

**Excerpt:** Linux VPS出现Read-only file system时，可能是挂载选项、文件系统错误、块设备故障或宿主存储异常。本文给出从确认受影响挂载点、保存日志到离线检查和恢复验证的低风险顺序。

VPS提示`Read-only file system`，表示当前写入目标所在的文件系统以只读方式提供，应用因此无法创建、修改或删除文件。它不等于“磁盘空间满了”，也不能靠给目录加`chmod 777`解决。

最重要的第一步是**停止反复写入和重启**，保留时间、报错、挂载状态与内核日志。若文件系统因错误或存储异常转为只读，直接强制改回读写可能掩盖证据，甚至扩大数据损坏。

## 先确认是哪一个挂载点只读

同一台Linux VPS可以有根分区、数据盘、容器卷、网络文件系统和临时文件系统。应用报错的路径属于哪个挂载点，决定后续处理对象。可先做只读检查：

```
findmnt -T /出现报错的路径
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f
df -hT
df -i
```

`findmnt -T`用于定位某个路径对应的挂载；`OPTIONS`中出现`ro`说明当前是只读挂载，`rw`表示读写。`df`同时用于排除容量或inode耗尽，但空间不足通常会报告`No space left on device`，不是同一个错误。

## 先排除“本来就应该只读”的情况

并非所有`ro`都代表故障。镜像、安装介质、某些容器根层、安全加固挂载或显式使用`ro`选项的数据卷，本来就可能只读。检查`/etc/fstab`、容器编排配置和最近变更，确认该挂载是否设计为可写。

还要区分应用路径：程序可能写错到只读的容器层或系统目录，而真正的数据卷挂在另一个位置。此时修复方向是更正路径或卷映射，不是改变整个主机的挂载权限。

## 保存内核与启动日志

如果原本可写的文件系统突然只读，重点检查故障时间附近的内核信息：

```
journalctl -k --since "30 minutes ago"
dmesg -T
journalctl -p err..alert --since "30 minutes ago"
```

关注I/O error、filesystem error、buffer、reset、timeout、EXT4、XFS、NVMe、virtio或块设备相关信息。命令输出可能包含主机名、设备标识和业务路径，提交工单前应脱敏，但不要删掉时间戳和连续上下文。

`dmesg`缓冲区会滚动，重启也可能让现场变化；因此先保存证据，再决定是否停机或重启。若控制台同时提示宿主存储故障，应优先联系VPS服务商，并提供实例、时间和只读检查结果。

## 为什么不建议立刻执行remount,rw

`mount -o remount,rw`只是请求把挂载改回读写。若只读来自明确配置，它可能改变安全边界；若只读来自文件系统错误或底层I/O异常，命令可能失败，或者短暂成功后再次只读。根因没有解除时继续写入，不是可靠恢复。

只有在确认设备健康、文件系统状态允许、挂载本应读写且已经有可恢复备份后，才应按照对应文件系统和发行版文档执行恢复。生产环境中，先在控制台或救援系统准备回退路径。

## EXT4与XFS不能套用同一条修复命令

| 文件系统 | 常见检查工具 | 重要边界 |
| --- | --- | --- |
| ext4 | `fsck`/`e2fsck` | 通常应对未挂载文件系统操作；根分区常需救援环境或维护启动 |
| XFS | `xfs_repair` | 使用XFS专用工具；不要把ext4命令照搬到XFS |
| 网络文件系统 | 客户端挂载、服务端导出与网络日志 | 只修客户端权限可能无效，需检查远端服务与连接 |
| 容器卷 | 宿主挂载和卷配置 | 先判断只读来自容器参数还是宿主文件系统 |

不要对仍在读写挂载的文件系统盲目运行修复工具，也不要在没有备份的情况下使用不了解的强制参数。云盘快照能提供恢复点，但快照是否应用一致、能否跨盘恢复，取决于平台能力和业务写入状态。

## 根分区只读时的恢复思路

1.  通过云控制台确认实例、磁盘和近期平台事件，保留屏幕与时间；
2.  若SSH仍可用，只执行必要的只读检查并导出关键日志；
3.  停止数据库、容器或持续写入任务，避免错误重试淹没现场；
4.  创建符合平台规则的快照或备份；若存储疑似损坏，先确认快照风险；
5.  进入救援环境、维护模式或把系统盘挂到另一台授权实例；
6.  根据实际文件系统使用对应的离线检查与修复工具；
7.  恢复挂载后先做数据与服务校验，再逐项开放写入和流量。

若没有控制台、救援模式或离线挂载能力，不要自行尝试高风险强制修复，应把证据提交服务商处理。

## 恢复后不能只看“能创建文件”

写入恢复只是第一层。还应验证：

-   挂载来源、文件系统类型和`rw`状态是否正确；
-   内核日志是否继续出现I/O、超时或文件系统错误；
-   数据库能否完成一致性检查，关键表和近期写入是否完整；
-   容器卷、上传目录、缓存、日志和备份路径是否都指向预期磁盘；
-   重启后`/etc/fstab`或卷配置能否得到相同结果；
-   监控是否覆盖磁盘错误、容量、inode、延迟和挂载状态。

如果此前还出现`df`与`du`不一致、inode耗尽或已删除文件未释放，可参考[VPS磁盘满的分层排查方法](https://www.jiyueip.com/article/13247)；这些问题可能同时发生，但不能用清理大文件替代只读根因诊断。

## 怎样降低再次发生的影响

把数据盘、系统盘和备份目标分开规划；定期验证备份能否恢复；对内核I/O错误、磁盘延迟、只读挂载和文件系统使用率建立告警；变更`fstab`、卷映射或磁盘扩容前保存配置和回滚步骤。对数据库等有状态服务，应使用应用一致的备份，而不是只依赖某一时刻的磁盘快照。

## 结论

`Read-only file system`是写入路径的文件系统状态信号，不是普通目录权限问题。正确顺序是定位挂载点、确认是否本来只读、保存内核证据、判断文件系统与块设备状态，再在可回退的离线环境中修复。强制重新挂载应是有依据的恢复动作，而不是看到报错后的第一条命令。

**Tags:** Linux服务器, VPS, VPS监控, 服务器运维, 网络故障排查

**Categories:** 网络技术

---