Linux只读文件系统报错解决方法

直接告诉你结论：90% 的 Read-only file system 报错，不是硬件坏了，是内核触发了保护机制，把分区降级成了只读。只要没强行写入或者格式化，数据基本都在。但别高兴太早，修复前必须搞清楚一个关键问题：到底是硬盘物理挂了，还是文件系统出了逻辑错误。这个顺序一旦搞反，本来能修的问题可能直接变成不可逆的灾难。

先判断是不是硬盘真坏了

但先别急着抄起 fsck 或 remount,rw 就上——底层有没有物理风险，得先看清楚：

• 用 dmesg -T | tail -50 扫一眼：重点搜 EXT4-fs error、I/O error、ATA bus error、SMART 这几个关键词。只要出现任何一个，立刻停掉所有写操作。
• 翻翻 /proc/mounts：cat /proc/mounts | grep "ro|errors="，如果看到 errors=remount-ro，说明文件系统之前出过错，被自动降级了，这属于软件层的保护机制，不是硬件坏。
• 用 smartctl -a /dev/sdX（替换成实际设备，比如 sda）检查硬盘健康：重点盯住 Reallocated_Sector_Ct、Current_Pending_Sector、UDMA_CRC_Error_Count 这三项。只要不为零并且数值在持续飙升，意味着硬盘离彻底报废不远了。

这三步里只要有一步报警，就不要碰 e2fsck 了，立刻用 ddrescue 把整块盘克隆出来再处理。

能 remount,rw 就别急着 fsck

其实，很多场景下只是内核临时保护了一下，文件系统本身没有坏。这时候硬跑 fsck，反而可能引入新问题。

• 先试最简单的：mount -o remount,rw /（根分区）或者 mount -o remount,rw /mnt/data（其他挂载点）。
• 验证一下：touch /test_rw && rm /test_rw，能成功就说明问题解决了。
• 失败的话，常见原因有这些：有进程正在占用这个分区（比如日志服务还在写），或者 /etc/fstab 里写死了 ro 选项。
• 如果提示 device is busy，用 lsof +D /mount/point 查查是哪个进程在占着不放。实在不行，可以加 -l 参数懒卸载：umount -l /mount/point。

必须 fsck 时，记住三条铁律

fsck 不是万能钥匙，用错了等于自毁前程：

• 绝对不能在挂载状态下运行。看到 dev/sda1 is mounted 的提示，选 n 中止。先 umount /dev/sda1（卸不掉就进单用户模式或者用 Live CD）。
• 按文件系统类型选对工具。ext4 用 e2fsck -f -y /dev/sda1，xfs 用 xfs_repair /dev/sda1，这两个不能混用。
• 千万别跳过 -f 参数。默认情况下，已经挂载过的分区会被跳过检查，加了 -f 才能强制扫描出那些隐藏的损坏。
• 修复后一定要 mount /dev/sda1 /mount/point 再验证一遍，不要光相信输出里的 clean 字样。

/etc/fstab 配置里容易被忽略的坑

如果重启之后又变回只读，那问题八成出在这里：

• 打开 /etc/fstab，检查目标分区那行末尾，有没有 ro 选项，或者是不是漏掉了 rw。
• 一个常见错误写法：/dev/sda1 /data ext4 defaults 0 2。看起来没问题，但某些发行版或内核版本下，defaults 隐含了 relatime 但不保证 rw。显式写成 defaults,rw 更稳妥。
• 如果分区用了 LVM 或加密卷，确认 systemd 服务（比如 lvm2-monitor.service）已经启用。否则，fstab 里的设备名可能解析失败，系统会退回到只读的 fallback 模式。

真正麻烦的从来不是报错本身，而是有人在 dmesg 明确显示 I/O error 后，还坚持用 e2fsck -y。那一刻，数据恢复的难度就从“找备份”直接升级到“买专业恢复服务”。