服务器文件系统只读修复：从定位到挂载恢复的完整步骤

服务器文件系统突然变成只读，最直接的表现是无法新建文件、数据库写入报错、面板提示权限拒绝。
多数情况下这不是权限问题，而是内核检测到磁盘 I/O 错误或文件系统损坏后，主动把分区挂载状态改成了只读，用来防止数据被进一步破坏。
处理前先确认现象和原因，再决定是否执行修复。

先确认是不是真的只读挂载

登录服务器后，用 mount 查看目标分区当前挂载参数。

mount | grep -E "on / |on /data"

如果输出里出现 (ro, 或 (ro)，说明该分区确实以只读方式挂载。
常见输出类似：

/dev/vda1 on / type ext4 (ro,relatime,data=ordered)

同时查看内核日志里的错误线索：

dmesg -T | tail -n 50

重点看有没有 I/O error、EXT4-fs error、remounting filesystem read-only、XFS (vdb1): Corruption detected 这类字样。
日志能帮助区分是文件系统损坏、磁盘坏道，还是云盘掉线。

修复前的准备和风险说明

文件系统修复涉及数据安全，动手前需要明确几点：

• 如果服务器上有正在运行的重要业务，优先在业务低峰期操作，或先做快照。
• 云服务器建议先在控制台创建系统盘或数据盘快照，再执行修复。
• 物理机可以先确认是否有 RAID 报警、硬盘指示灯异常，避免在硬件已经故障时反复修复。
• 根分区 / 无法直接卸载，通常需要进入单用户模式或救援模式操作。
• 数据盘如 /data 可以先停掉占用它的进程，再卸载修复。

如果日志里大量出现 I/O error，并且同一块盘反复只读，修复后仍会复发，这时应优先考虑更换磁盘或迁移数据，而不是反复跑修复命令。

数据盘只读的修复流程

以 /dev/vdb1 挂载到 /data 为例。

第一步，停止占用该分区的进程。
用 lsof 或 fuser 找出占用者：

fuser -m /data

根据输出停掉对应服务，例如 Nginx、MySQL 或 Docker 容器。

第二步，卸载分区：

umount /data

如果提示 target is busy，说明还有进程占用，可先用 lsof /data 确认再停服务，不要直接 umount -l 强制卸载，容易造成数据不一致。

第三步，执行修复。
ext4 用：

fsck -y /dev/vdb1

xfs 用：

xfs_repair /dev/vdb1

注意 xfs 修复前分区必须处于卸载状态，且 xfs_repair 不能对已挂载的 XFS 使用。
如果 xfs 提示日志需要清理，可先执行 xfs_repair -L /dev/vdb1，但这一步会清空日志，只有在确认没有其他办法时才使用，最好先备份。

第四步，重新挂载并验证：

mount /data
touch /data/test_write && echo ok

能成功创建文件说明写权限已恢复。
再执行 mount | grep /data，确认挂载参数里不再有 ro。

根分区只读怎么处理

根分区无法在线卸载，通常有两种方式进入可修复环境。

方式一，单用户模式。
在 GRUB 启动菜单按 e 编辑启动项，在 linux 行末尾加上 single 或 init=/bin/bash，然后按 Ctrl+X 启动。
进入后根分区通常仍是只读，需要重新挂载：

mount -o remount,rw /

如果重新挂载为读写失败，说明文件系统已经损坏，需要先卸载修复。
使用 init=/bin/bash 时，先执行：

mount -o remount,ro /
fsck -y /dev/vda1
mount -o remount,rw /

完成后执行 reboot -f 重启。

方式二，使用云厂商控制台或 IPMI 挂载救援系统，把系统盘作为数据盘挂载后执行 fsck。
这种方式更稳妥，适合不熟悉单用户模式的用户。

容易踩的几个坑

• 不要在根分区仍挂载为读写时直接跑 fsck，可能造成更严重的元数据损坏。
• 不要忽略 fstab 写错导致的只读。如果 /etc/fstab 中某个分区参数写错，系统进入紧急模式后可能以只读挂载。用 mount -o remount,rw / 恢复后检查 fstab 内容。
• 云盘只读不一定是文件系统问题。部分云盘在触发性能上限或后端异常时会临时转为只读，这种情况需要查看云监控或联系服务商确认，而不是反复修复文件系统。
• 修复完成后不要立刻删除日志。保留 dmesg 或 /var/log/messages 里的报错，方便判断是否复发。
• ext4 的 fsck -y 会自动修复，但修复结果不一定能恢复所有文件，重要数据应提前备份。

恢复后的检查项

修复并重新挂载后，建议按下面顺序确认：

1. 用 mount | grep 目标分区 确认没有 ro 参数。
2. 用 touch 在目标目录创建测试文件，确认可写。
3. 用 df -h 确认分区容量和挂载点正常。
4. 重启一次服务器，确认开机自动挂载正常。
5. 观察 dmesg -T 是否再次出现 I/O 错误。

如果重启后再次变成只读，说明底层磁盘或云盘存在问题，应优先备份数据并联系服务商排查硬件或后端状态，不要只依赖文件系统修复。

常见疑问

服务器只读修复后会丢数据吗？

fsck 和 xfs_repair 的目标是修复文件系统一致性，正常情况下不会主动删除正常文件，但损坏的目录项或元数据可能被清理。
修复前做快照或备份是最稳妥的做法。

为什么修复完重启又变只读？

常见原因有三个：磁盘存在坏道或云盘后端异常、RAID 阵列降级、fstab 配置错误。
需要结合 dmesg 和硬件状态一起判断，而不是重复执行修复命令。

XFS 和 ext4 的修复命令能混用吗？

不能。
ext4 使用 fsck，XFS 使用 xfs_repair。
用错命令可能提示无法识别或造成额外风险。
执行前先用 lsblk -f 或 blkid 确认文件系统类型。