Linux 报 Read-only file system 怎么排查？挂载、I/O 错误与离线修复

看到 Read-only file system 后先停写并保留证据：这不是普通的 chmod 权限不足。Linux 可能按配置把挂载点设为只读，也可能在检测到文件系统或磁盘错误后自动切为只读，容器卷还可能被明确以 :ro 挂载。操作入口是 SSH、云控制台终端或救援模式；先确认报错路径属于哪个挂载点、设备和文件系统，不要立刻执行 mount -o remount,rw 强行恢复写入。

查看挂载和日志通常不收费；创建云盘快照、克隆盘、救援实例或替换磁盘可能收费。重新挂载不会自动修好损坏，fsck 会修改文件系统元数据，错误设备或在线修复存在数据丢失风险。数据库、队列和上传目录应先停写，重要磁盘优先创建可回退快照或克隆，但要知道崩溃状态快照不等于应用一致备份。

先找到报错路径真正属于哪个挂载点

把“报错路径”替换为应用无法写入的实际目录。下面命令只读设备、文件系统和挂载选项，不会改变数据。

findmnt -T /报错路径 -o TARGET,SOURCE,FSTYPE,VFS-OPTIONS,FS-OPTIONS
lsblk -f
df -hT /报错路径
df -i /报错路径

findmnt 输出包含 ro 才能证明该层是只读。只有 Permission denied、而挂载选项仍是 rw 时，应转向属主、模式位、ACL、SELinux/AppArmor 或容器 UID；可参考Linux 文件权限排查。磁盘或 inode 100% 会造成写入失败，但不一定显示为只读，应按Linux 磁盘满教程单独处理。

再判断是人为只读还是故障保护

证据	更可能的原因	下一步
/etc/fstab、容器配置明确含 ro	人为或部署配置	核对目的后改配置并受控重挂载
内核日志有 EXT4-fs error、I/O error、Buffer I/O	文件系统或底层设备故障	停写、快照/克隆、离线检查
云盘事件或监控有 I/O 异常	云盘、宿主或连接问题	保留事件，按云平台恢复路径处理
只有容器内只读，宿主目录可写	卷以只读方式挂载或容器根文件系统只读	检查 Compose/容器 Mounts，不改宿主文件系统

怎样读取内核和启动日志

先记录首次报错时间，再查看同一时间窗口。日志可能含设备名、主机名和业务路径，对外提交前应遮挡敏感信息。

sudo journalctl -k --since "30 minutes ago" --no-pager
sudo dmesg -T | grep -Ei 'I/O error|EXT4-fs error|XFS|Buffer I/O|read-only'
sudo journalctl -b -p warning --no-pager

ext4 可按挂载参数在遇到错误时继续、重新挂载为只读或触发 panic；云服务器常见的保护表现是内核将文件系统切为只读，避免继续写坏元数据。日志如果指向块设备超时、介质错误或设备消失，先处理底层盘与云平台事件，不要只修文件系统表面症状。

配置本来就是 ro：确认目的后再改

备份、镜像、只读共享目录和容器根文件系统可能故意设置为只读。先检查 /etc/fstab、systemd mount 单元、Docker Compose 的 read_only 或卷后的 :ro。如果应用升级后突然需要写某个目录，应优先为缓存、上传或临时文件提供独立可写路径，而不是取消整个容器的只读保护。

只有确认设备健康、只读来自错误配置且已保存原配置时，才在维护窗口修改并重挂载。对根分区或关键数据库盘，先从测试或克隆盘验证。不要把临时的在线 remount,rw 当成永久修复；重启后仍会读取原挂载配置。

ext4 出错：只能在卸载后做正式 e2fsck

e2fsck 适用于 ext2/ext3/ext4。官方手册明确说明，一般不应在已挂载文件系统上运行；即使使用只读检查选项，挂载中的结果也可能无效。先用 lsblk -f 与 findmnt 确认真实设备，不从旧工单复制 /dev/sda1。

非根数据盘应停止使用它的应用，确认没有进程占用，卸载后再在维护窗口检查。根分区不能在正常运行系统中卸载，应进入云平台救援模式、恢复环境，或把克隆盘挂到同区域辅助实例。下面只是 ext4 的离线检查形式，设备名必须替换；正式修复前先有快照或克隆。

sudo e2fsck -f /dev/实际的未挂载ext4分区

交互提示涉及元数据修改，无法理解时不要用 -y 自动同意全部修复。XFS、Btrfs 和其他文件系统要使用各自工具与官方流程，不能对 XFS 运行 e2fsck。任何修复都可能把无法归属的内容放入恢复目录或丢弃损坏元数据，修完必须做应用层校验。

底层云盘或硬件异常怎么处理

查看云控制台的实例事件、云盘状态、I/O 延迟、错误和队列。平台事件、宿主故障或云盘连接异常应优先按官方工单与迁移路径处理。快照前停止数据库写入或执行应用一致性冻结能提高可恢复性；如果源盘持续报 I/O 错误，反复全盘扫描可能加重压力，应优先克隆到健康盘再分析。

恢复方案通常是：保留原盘只读证据，在克隆盘完成文件系统与应用校验，再把新盘接入服务。不要在没有备份时格式化原盘，也不要因为控制台显示“正常”就忽略内核 I/O 日志。

容器内 Read-only file system 单独排查

宿主机可写而容器报错时，先读取容器 Mounts 和 Compose 最终配置。以下命令只读；把容器名替换为实际值。

docker inspect 容器名 --format '{{json .Mounts}}'
docker inspect 容器名 --format '{{.HostConfig.ReadonlyRootfs}}'
docker compose config

卷的 RW:false、Compose 中的 :ro 或 read_only: true 都可能是设计要求。为确实需要写入的路径声明独立 volume 或 tmpfs，并先确认数据保留方式。不要关闭整个只读根文件系统来迁就一个缓存目录，也不要使用 docker compose down -v，它会删除命名卷。

恢复写入前的验证顺序

1. 确认底层设备、云盘事件和内核日志不再出现新的 I/O 或文件系统错误。
2. 用 findmnt 确认目标挂载点为预期的 rw，没有改错另一个同名目录。
3. 在专用测试目录进行一次小文件写入、同步、读取和删除，不直接拿数据库文件测试。
4. 逐个启动应用，检查数据库一致性、上传、日志、队列和备份任务。
5. 重启后复核挂载、服务和内核日志，证明永久配置正确。

任一步出现新错误，立即停写并回到只读保护。回退时卸载新盘或恢复原挂载配置，保留故障盘与日志；已经切换到克隆盘的业务不要双边同时写。需要完整演练恢复路径时可继续查看云服务器备份恢复演练。

官方与上游资料

• util-linux：mount 与只读挂载说明
• e2fsprogs：e2fsck 手册
• Linux Kernel：ext4 日志机制

以上资料于 2026 年 9 月 3 日核验。不同文件系统、云盘和发行版的恢复工具不同，执行修复前必须以实际 FSTYPE 与平台文档为准。