Linux提示“只读文件系统”？重新挂载前先找出原因

1. 确认失败路径背后的文件系统

针对产生EROFS的路径运行 `findmnt --target /path/that/failed -o TARGET,SOURCE,FSTYPE,OPTIONS`，不要猜磁盘名。util-linux手册说明--target接受文件或目录并显示对应文件系统。准确记录TARGET、SOURCE、FSTYPE、OPTIONS。命令失败或目标不明确时，先在同一命名空间确认现有父路径的挂载，再选择修复设备。

这能识别误导性情况：路径可能位于只读绑定挂载，而原位置仍可写；也可能处于不同挂载命名空间的容器、网络文件系统或只读快照。如果失败发生在容器或服务内，在具备合法管理权限时从同一命名空间检查；主机看到的状态可能不是拒绝写入的状态。

SOURCE若为远程导出、loop设备、device-mapper卷或快照，应保留这一身份。因为名称看起来相似就修复另一物理分区，可能加重故障。

2. 改变状态之前保存证据

故障仍在时记录挂载与近期内核消息。只读查看命令包括findmnt的上述用法、`journalctl -k -b --no-pager`，以及有权限时的 `dmesg`。分享前隐去主机名、序列号和敏感路径。没有systemd的系统使用其可用内核日志工具；dmesg -T的人类可读时间在休眠恢复后可能不准确，应保存原始输出，不编造精确时间顺序。

在保存的日志中寻找第一项相关错误，而非只看后续“只读”消息。I/O error、journal abort、EXT4-fs error、device reset、link down、multipath failure、write-protected指向不同原因。Red Hat记录过所有存储路径丢失、日志中止、随后文件系统只读的实际案例。

机器仍承载重要数据时，先停止非必要写入并安排备份或故障切换，再试验。反复重新挂载不能证明底层路径健康。

3. 区分是哪一层变成只读

有意策略：OPTIONS含ro，介质或快照本来不可变，/etc/fstab要求ro，绑定挂载只读，或远端以只读导出共享。应在拥有该策略的层修正；本地重新挂载可能只是临时措施、被拒绝或并不适用。

保护状态：日志出现文件系统或日志错误。ext4文档将errors=remount-ro描述为出错后转只读。已发布Linux 6.16代码设置紧急只读标记而不设置普通SB_RDONLY，并在ext4选项中显示emergency_ro。核对所装内核行为；简单的rw字段或没有这个较新标记，都不能证明写入安全。以日志和实际失败为依据。

底层存储保护或故障：重新挂载报告write-protected，或日志包含设备、总线、控制器、线缆、多路径、介质错误。先修复或替换故障路径。文件系统检查可能修复元数据损坏，但不能修好消失的SAN路径、坏线缆或控制器重置。

远程或虚拟层：NFS、CIFS、FUSE、云卷、容器挂载或不可变镜像可能因本地磁盘之外的原因返回EROFS。按对应层的健康与策略证据排查，不套用ext4修复办法。

4. 卸载后使用对应文件系统的检查工具

证据指向文件系统损坏时，安排停机、故障切换或启动救援环境，以便卸载目标。卸载后再次确认设备。e2fsck手册指出，对已挂载的ext2、ext3或ext4运行检查通常不安全；即使名义上只读，挂载中的检查结果也可能无效。

不要把“运行fsck”理解为“对看起来正确的设备运行fsck -y”。通用前端调用对应文件系统的工具，各类型恢复机制不同。Btrfs文档建议先卸载，并明确不要使用--repair，除非有经验的开发者或用户建议。查看已记录FSTYPE的当前手册，尽可能备份，并确认操作是否会修改元数据。

若日志显示存储路径问题，先稳定路径再修元数据。否则写入恢复后，已修复的文件系统可能再次损坏。

5. 处理原因后重新挂载，再验证

确认只读并非有意策略且原因已处理后，使用所记录的准确TARGET，按文件系统或平台流程恢复写入。常见本地用法为 `mount -o remount,rw /exact/mountpoint`，但它不是万能修复；远程、绑定、容器、快照和托管卷可能不适用。

分层验证：对同一失败路径重新运行findmnt，在指定安全目录做一次受控写入、读回并移除；再检查内核日志有无新增文件系统或I/O错误，并观察正常负载是否复发。

只有目标挂载可写、测试经sync或应用往返后仍成功、无新增存储或文件系统错误且只读状态不再回来，才能认定处理完成。若复发，就不要继续把重新挂载当成修复，应携带证据排查设备、控制器、网络路径或平台问题。