VPS提示Read-only file system，表示当前写入目标所在的文件系统以只读方式提供，应用因此无法创建、修改或删除文件。它不等于“磁盘空间满了”，也不能靠给目录加chmod 777解决。
最重要的第一步是停止反复写入和重启，保留时间、报错、挂载状态与内核日志。若文件系统因错误或存储异常转为只读，直接强制改回读写可能掩盖证据，甚至扩大数据损坏。
先确认是哪一个挂载点只读
同一台Linux VPS可以有根分区、数据盘、容器卷、网络文件系统和临时文件系统。应用报错的路径属于哪个挂载点，决定后续处理对象。可先做只读检查：
findmnt -T /出现报错的路径
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f
df -hT
df -ifindmnt -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 |
| 网络文件系统 | 客户端挂载、服务端导出与网络日志 | 只修客户端权限可能无效，需检查远端服务与连接 |
| 容器卷 | 宿主挂载和卷配置 | 先判断只读来自容器参数还是宿主文件系统 |
不要对仍在读写挂载的文件系统盲目运行修复工具，也不要在没有备份的情况下使用不了解的强制参数。云盘快照能提供恢复点，但快照是否应用一致、能否跨盘恢复，取决于平台能力和业务写入状态。
根分区只读时的恢复思路
- 通过云控制台确认实例、磁盘和近期平台事件，保留屏幕与时间；
- 若SSH仍可用，只执行必要的只读检查并导出关键日志；
- 停止数据库、容器或持续写入任务，避免错误重试淹没现场；
- 创建符合平台规则的快照或备份；若存储疑似损坏，先确认快照风险；
- 进入救援环境、维护模式或把系统盘挂到另一台授权实例；
- 根据实际文件系统使用对应的离线检查与修复工具；
- 恢复挂载后先做数据与服务校验，再逐项开放写入和流量。
若没有控制台、救援模式或离线挂载能力，不要自行尝试高风险强制修复，应把证据提交服务商处理。
恢复后不能只看“能创建文件”
写入恢复只是第一层。还应验证：
- 挂载来源、文件系统类型和
rw状态是否正确； - 内核日志是否继续出现I/O、超时或文件系统错误；
- 数据库能否完成一致性检查，关键表和近期写入是否完整；
- 容器卷、上传目录、缓存、日志和备份路径是否都指向预期磁盘；
- 重启后
/etc/fstab或卷配置能否得到相同结果； - 监控是否覆盖磁盘错误、容量、inode、延迟和挂载状态。
如果此前还出现df与du不一致、inode耗尽或已删除文件未释放，可参考VPS磁盘满的分层排查方法；这些问题可能同时发生，但不能用清理大文件替代只读根因诊断。
怎样降低再次发生的影响
把数据盘、系统盘和备份目标分开规划；定期验证备份能否恢复；对内核I/O错误、磁盘延迟、只读挂载和文件系统使用率建立告警；变更fstab、卷映射或磁盘扩容前保存配置和回滚步骤。对数据库等有状态服务，应使用应用一致的备份，而不是只依赖某一时刻的磁盘快照。
结论
Read-only file system是写入路径的文件系统状态信号，不是普通目录权限问题。正确顺序是定位挂载点、确认是否本来只读、保存内核证据、判断文件系统与块设备状态，再在可回退的离线环境中修复。强制重新挂载应是有依据的恢复动作，而不是看到报错后的第一条命令。
