Linux怎么解决“Read-only file system”报错

直接告诉你结论：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`。那一刻，数据恢复的难度就从“找备份”直接升级到“买专业恢复服务”了。