Linux提示Read-only file system怎么解决

上传文件、写日志或更新软件时，终端突然提示 Read-only file system，不少人的第一反应是执行重新挂载命令，把分区强制改回可写。这个动作有时能暂时恢复写入，但底层存在I/O错误或文件系统损坏时，也可能让问题继续扩大。

先暂停数据库写入、部署和批量复制，确认到底是哪一个挂载点变成只读，再根据内核日志决定修复方式。只读往往是保护结果，不一定是故障起点。

先确认报错发生在哪个路径

用一个最小写入测试确认范围，不要拿重要文件反复覆盖：

touch /path/to/problem/.write-test
findmnt -T /path/to/problem

findmnt -T 会显示该路径实际属于哪个文件系统、设备和挂载点。网站目录可能位于独立云盘、LVM、容器挂载或网络存储中，只看根分区容易查错对象。

只有某个文件无法修改时，还要检查文件权限、不可变属性和目录属主。真正的只读挂载通常会影响同一挂载点内的多处写入，并明确返回只读文件系统错误。

继续记录挂载参数与设备对应关系：

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS -T /path/to/problem
lsblk -f

OPTIONS 中出现 ro 表示当前以只读方式挂载，rw 才是可写。系统启动后一直只读，可能来自 /etc/fstab、镜像设置或手动挂载；运行一段时间后突然从可写变只读，更应关注文件系统和存储错误。

容器里的只读还可能来自容器自身的只读根文件系统或卷挂载参数。此时宿主机磁盘正常，也不能直接在容器内通过 mount -o remount,rw 改变平台设置。

空间写满通常返回 No space left on device，与只读错误并不相同，但两者可能同时出现。先把容量和inode数据一并保存：

df -hT
df -i

分区已满时，优先清理可确认的缓存、旧日志或无用备份，不要直接删除数据库文件。空间恢复后再次检查挂载状态；腾出空间不会自动修复已经发生的文件系统错误。

查看本次启动中的存储和文件系统消息：

sudo journalctl -k -b --no-pager | tail -n 200
sudo dmesg -T | tail -n 200

关注I/O error、Buffer I/O error、EXT4-fs error、XFS错误、设备重置和文件系统被重新挂载为只读等信息。ext4支持在检测到错误时按配置重新挂载为只读，这种情况下 ro 是内核为了减少进一步写入损坏采取的保护措施。

把报错时间、设备名和云平台磁盘监控对齐。底层云盘异常、宿主机存储问题、文件系统损坏和异常关机后的恢复失败，处理路径并不相同。

fsck 通常需要在目标文件系统未挂载时执行。对正在使用的根分区或数据库分区直接修复，可能让内核与修复工具同时修改元数据。

更稳妥的方式是在控制台进入救援模式，或把数据盘卸载后再使用与文件系统匹配的检查工具。ext4常用 e2fsck，XFS的检查与修复流程不同，不能把同一条命令套在所有文件系统上。

执行前先做快照或可恢复备份，并确认备份不只存在于同一块故障磁盘。检测到持续I/O错误时，应先联系云服务商确认存储状态，再决定修复或更换磁盘。

只有在确认文件系统本身健康、只读来自明确的挂载配置或临时维护操作时，才评估重新挂载：

sudo mount -o remount,rw /mount/point

把 /mount/point 换成实际挂载点。命令失败时不要追加更激进参数；命令成功后也要继续观察内核日志和写入测试。底层错误没有消失，系统可能再次切回只读。

旧服务器已经出现反复只读和磁盘告警时，可以在 萤光云 准备相近系统做恢复验证，也可以借助按小时计费的 LightNode 建立并行环境。迁移时优先从已验证的备份恢复，不要把损坏文件系统整盘复制后直接上线。

确认目标挂载点显示为 rw，创建、修改和删除测试文件都正常；数据库、日志和网站上传能够持续写入。随后观察一个业务高峰，内核日志不应再出现新的文件系统错误或设备重置。

最后安排一次可控重启，验证 /etc/fstab、设备标识和启动挂载结果。只在当前会话里恢复写入，但重启后再次只读，说明问题还没有闭环。

服务器重启后恢复可写，还需要处理吗？

需要。重启可能完成日志回放或暂时恢复设备，但仍应检查上次启动的内核日志、磁盘监控和文件系统状态，确认没有持续错误。

可以直接把errors=remount-ro改成continue吗？

不建议。继续写入可能让损坏扩大。该设置改变故障后的处理方式，不会修复已经存在的存储或文件系统问题。