场景与思路
写入时报 Read-only file system，多数情况不是权限问题，而是内核在检测到 I/O 错误后主动把该文件系统重新挂载为只读，防止损坏继续扩大。因此排查顺序是先取证：看 dmesg 或内核日志里有没有 I/O error、EXT4-fs error、XFS 元数据错误，再确认当前挂载选项是否真的带 ro。在确认硬件状态之前不要去 remount rw 强行恢复写入，那只是把问题盖住；正确处置是备份可读数据、安排维护窗口做离线检查，必要时更换磁盘。
基本信息
| 场景 | 服务写日志、写数据时报只读文件系统错误 |
|---|---|
| 目标 | 先定根因是硬件、文件系统损坏还是配置问题 |
| 处置链路 | dmesg 或 journalctl -k 取证 → mount 看挂载选项 → 离线 fsck 或 xfs_repair |
| 判定要点 | 出现 I/O error 与介质错误时优先按硬件问题处理 |
| 风险提示 | 强行 remount rw 继续写入会加重元数据损坏 |
典型使用场景
- 应用突然大量写失败，日志里出现只读错误
- 内核日志持续刷文件系统错误
- 云盘或共享存储异常后文件系统变只读
- 维护窗口内做离线修复前的状态确认
- 恢复写入后复现验证，判断是否为反复出现的问题
三步处置
三步处置
dmesg -T | grep -i -E 'I/O error|remount|read-only|EXT4-fs error|XFS' | tail -n 50
journalctl -k --since '1 hour ago' | grep -i -E 'error|read-only' | tail
mount | grep ' / ' # 确认挂载选项是否含 ro
findmnt -no OPTIONS / # 更精确地取挂载选项
mount -o remount,rw / # 仅在确认无硬件问题时执行
umount /data && fsck -f /dev/sdb1 # ext 系列离线修复
umount /data && xfs_repair -n /dev/sdb1 # XFS 先预检再决定是否修复变只读的原因对照
| 原因 | 线索 | 处置方向 |
|---|---|---|
| 内核检测到 I/O 错误 | dmesg 中有 I/O error 或介质错误 | 备份数据，按硬件故障流程处理并安排换盘 |
| 文件系统损坏 | 报 EXT4-fs error 或 XFS 校验失败 | 维护窗口内离线 fsck 或 xfs_repair |
| 存储链路问题 | 共享存储或云盘后端异常 | 联系存储或云厂商，客户机内修复意义有限 |
| 挂载参数配置 | fstab 或内核参数里写了 ro | 修正参数后重新挂载 |
remount rw 只是临时把问题盖住。底层盘已出现 I/O 错误时继续写入会让损坏持续扩大，正确顺序是先备份可读数据，再评估换盘或离线修复。
云盘变只读还可能是配额超限或平台侧事件。排查时同时查看监控与云平台的事件记录，避免只在客户机内反复折腾。