直接答案：Read-only file system 说明写入目标当前以只读方式提供，但原因可能是管理员主动挂载为 ro、镜像/快照本身只读，或 ext4/XFS 检测到 I/O/元数据错误后为保护数据切为只读。先停止非必要写入、保存内核日志和挂载/设备信息，并从云控制台做一致性评估和快照/克隆；不要反复 remount,rw 或在仍挂载的生产文件系统上直接运行修复工具。若有硬件或底层 I/O 错误，应先处理设备与副本，再在离线副本上检查。
本文面向根分区、数据盘或容器宿主卷突然只读。若只是单个文件没有写权限，错误通常是 Permission denied，应检查属主、模式、ACL 或 SELinux，而不是文件系统修复。
本文按 2026 年 9 月可查的官方文档核对。示例命令以只读取证为主；凡涉及删除、覆盖、重启、权限、网络或数据库参数的动作，都应先确认操作对象、备份、维护窗口和带外恢复入口。不同发行版与软件版本的路径可能不同，必须先查询实际配置再改。
先用证据判断故障在哪一层
| 现象或检查点 | 它能说明什么 | 直接证据 | 不要误判为 |
|---|---|---|---|
| mount 显示 ro 且日志无错误 | 可能是启动参数、fstab或手工只读 | findmnt、fstab与启动记录 | 磁盘一定损坏 |
| dmesg 有 EXT4-fs error/I/O error | 内核检测到文件系统或块设备异常 | 内核日志、设备与云盘事件 | 普通权限问题 |
| 只有容器层只读 | 容器 read-only rootfs 或挂载选项 | docker inspect与宿主挂载 | 宿主磁盘损坏 |
| 重启后进入维护模式 | fstab、UUID或fsck需要处理 | 控制台、启动日志与设备映射 | 网络故障 |
| remount rw短暂成功后再只读 | 底层错误仍在复发 | 重复时间与I/O日志 | 修复已经完成 |
这张表的用法不是“看到一个关键词就改一个参数”，而是把客户端、DNS或边缘、Web 代理、应用、数据层依次分开。至少保留故障时间、完整 URL、状态码、关键响应头、同一时刻的服务日志和一份正常样本。只有时间能够对齐，才能判断两个现象是否属于同一次故障。
六步排查与修复顺序
1. 暂停写入并保留现场
停止会持续写盘的非关键服务，记录业务影响和首次只读时间。不要先清日志、重启或执行大规模复制；错误设备可能在持续退化，优先保护不可替代数据和证据。
2. 确认哪个挂载点只读
用 findmnt、lsblk -f 和 df -hT 将报错路径映射到挂载点、文件系统、LVM/RAID 与云盘。根分区、单独数据盘、NFS 和容器 overlay 的处理边界不同。
3. 读取内核与存储事件
查看故障窗口的 dmesg/journal，关注 I/O error、EXT4-fs、XFS、buffer、nvme 与 hung task。云服务器还要查控制台磁盘状态和宿主事件；客户机没有错误不代表底层一定健康。
4. 先制作可恢复副本
依据云平台与应用一致性要求创建快照或克隆，并另有数据库原生备份。若盘已不稳定，大量读可能加剧问题，需与平台支持评估优先级。记录校验、挂载和加密密钥。
5. 在离线副本检查文件系统
ext4 使用 e2fsck 前应确保目标未挂载；XFS 使用其对应工具和流程，不能混用。先在克隆盘或救援环境检查，再决定修复；任何自动确认所有修复的参数都可能造成不可逆数据丢失。
6. 恢复后验证设备与业务
重新挂载前核对 UUID、fstab 和只读/读写选项，先以最小服务启动。检查数据库一致性、文件校验、错误日志和云盘指标，跨过一次重启与写入高峰；若 I/O 错误复发，应迁移数据并更换底层设备。
可复制的只读取证命令
以下命令中的域名、服务名、路径和时间范围要替换为自己的真实值。先执行查询命令并保存原始输出；不要把“命令能运行”误当成“业务已恢复”。
text
findmnt -T /path/that/failed -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f
dmesg -T | grep -Ei 'I/O error|EXT4-fs|XFS|read-only|nvme|buffer' | tail -n 100
journalctl -k --since '30 minutes ago' --no-pager
e2fsck -n /dev/mapper/example-volume
findmnt -T /path/that/failed -o TARGET,SOURCE,FSTYPE,OPTIONS：把报错路径映射到真实挂载与选项lsblk -f：查看设备、文件系统、UUID与挂载关系dmesg -T | grep -Ei 'I/O error|EXT4-fs|XFS|read-only|nvme|buffer' | tail -n 100：筛选内核存储线索；完整日志仍应保存journalctl -k --since '30 minutes ago' --no-pager：读取指定窗口的内核日志e2fsck -n /dev/mapper/example-volume：只读检查示例；仅对确认的未挂载ext文件系统，设备名必须替换
如命令输出包含公网 IP、用户名、Cookie、令牌、数据库连接串或客户数据，分享工单前先脱敏。对比时保留时间戳、时区和命令本身，否则后来无法复现同一观察条件。
五个最容易扩大故障的误区
- 反复 remount,rw：若内核因错误保护性只读，会再次失败并可能扩大损坏。
- 挂载状态下直接 e2fsck 修复：可能与正在变化的元数据冲突，造成更严重后果。
- 把快照当完整备份：快照可能与源盘同故障域，也不保证数据库应用一致性。
- 看到只读就 chmod 777：文件系统只读时权限修改也无法写入，还会破坏安全边界。
- 只修文件系统不查底层设备：硬件、云盘或连接错误会让问题很快复发。
变更、回滚与数据边界
所谓回滚不是把只读强行改回读写，而是恢复到已知一致且设备健康的副本。任何 fsck、挂载或设备替换前保存日志、分区表、LVM信息和快照标识；先在克隆盘演练。如果修复后校验不一致或 I/O 错误复发，停止写入并切回未被继续修改的副本。数据库需按自己的恢复点和日志处理，不能只回滚文件系统快照。
如果只能先恢复服务、还不能确认根因，应把措施标记为“临时缓解”，例如限流、摘除单节点、切回上一配置或临时绕过一层代理。恢复后仍要在受控环境复现原因，并验证同类故障不会在下一次重启、发布或高峰重新出现。
统一验收清单
- [ ] 报错路径已映射到准确设备和挂载点
- [ ] 主动只读与错误触发只读已区分
- [ ] 内核与云盘事件已保存
- [ ] 不可替代数据有独立副本
- [ ] 文件系统检查在未挂载副本进行
- [ ] fstab与UUID匹配
- [ ] 恢复后数据库和文件校验通过
- [ ] 重启与高峰后无新增I/O或只读错误
验收必须同时覆盖机器内部和真实外部路径。首页返回 200 不能证明上传、长连接、登录、数据库写入或移动端都正常；同样，控制台显示“运行中”也不能证明应用已能处理请求。至少选一个正常请求、一个边界请求和一个失败请求，记录预期与实际结果。
相关内容与隔离测试入口
建议先阅读服务器磁盘满了、服务器磁盘IO高、快照和备份区别，把本问题放回完整请求链路。若生产环境不适合直接试验，可查看美国弹性云服务器的当前规格与库存，搭建与生产隔离的复现环境；测试机不能替代生产备份，价格、库存和可选配置以实时产品页为准。
常见问题
能直接执行 mount -o remount,rw 吗？
只有确认是预期配置问题且底层健康时才考虑。若日志有文件系统或I/O错误，强制写入可能扩大损坏。
e2fsck 可以修 XFS 吗？
不可以。工具必须与文件系统匹配；先用 findmnt/lsblk -f 确认类型，再按官方流程。
重启后恢复读写算修好吗？
不算。内核错误可能暂时未复现，需检查日志、设备指标、校验与持续写入。
只读会不会导致数据库损坏？
可能导致写失败、事务中断或服务退出。数据库恢复要查看其日志和一致性工具，不能只依赖文件系统重新可写。
云盘没有SMART数据怎么办？
结合客户机I/O日志、云监控、事件和平台工单。缺少SMART不代表底层健康，只是证据来源不同。