文件系统变成只读

适用范围

• 写入文件时提示 Read-only file system。
• 同一个文件系统上的所有共享都能读、不能写。
• 日志里出现 Remounting filesystem read-only 一类的信息。

不适用：只有某一个共享不能写，其他共享正常，多半是该共享的「只读」选项或权限设置，见权限错误：Permission denied和SMB 访问被拒绝或反复要密码。

开始排查前

先把数据复制出来，再考虑检查和修复

影响范围：文件系统变成只读，往往是它在保护自己：发现了错误，或者底层磁盘报了 I/O 故障，内核就把它切成只读，避免继续写入加重损坏。这时数据通常还能读，这正是抢救的窗口。

前置条件：另备一块容量足够的盘（或另一台机器）作为复制目标，并按型号和序列号核对过它不是出问题的那一块。注意 RAID、Btrfs RAID1、ZFS 镜像是冗余，不是备份：文件系统层面的损坏，镜像会同步损坏。

不要做的事：磁盘还在报 I/O 错误时，不要反复重启，不要强行重新挂载为可读写，不要先跑 fsck -y、不带 -n 的 xfs_repair、btrfs check --repair。这些命令会修改文件系统，对有硬件问题的盘可能让损坏扩大，而且不可撤销。

回退办法：只读复制出来的那一份就是你的退路。修复命令执行之后无法撤销。

排查步骤

1. 确认它真的是只读

# 在 OMV 的 shell 里执行（只读）
findmnt -l -o TARGET,FSTYPE,OPTIONS | grep -E 'TARGET|/srv/'
journalctl -k -b --no-pager | grep -iE 'read-only|remount|I/O error|EXT4-fs error|XFS|BTRFS'

findmnt 的选项列里出现 ro 就是只读。再看内核日志：

• Remounting filesystem read-only（ext4）、Shutting down filesystem（XFS）、Btrfs 的 forced readonly：文件系统因为错误进入了自我保护。
• I/O error, dev sdX, sector ...：底层的磁盘、数据线或控制器出了问题，只读只是结果。OMV 8.5.10 起，内核报这类 I/O 错误时会发告警邮件，前提是邮件通知可用且「杂项」通知项开启。
• 日志里没有任何错误，只是选项里有 ro：可能是有人或某个工具以只读方式挂载的。NTFS 盘还有一个常见原因：Windows 的休眠或快速启动留下了「脏」标志。在 Windows 上完整关机再接回即可。

2. 判断是硬件问题还是文件系统问题

# 在 OMV 的 shell 里执行（只读）；<磁盘> 例如 sda
smartctl -H -A /dev/<磁盘>

• 5（重新分配扇区）、197（待处理扇区）、198（无法修正扇区）的原始值在增长：磁盘在变坏。
• 199（UDMA CRC 错误）增长，或日志里有 ata 链路复位：多半是线缆、接口或电源的问题，换线重插。
• SMART 正常，日志里也没有 I/O 错误，只有文件系统自己报错：多半是元数据损坏，常见诱因是异常断电或内存故障。

各属性的含义见S.M.A.R.T.：监控硬盘健康。

3. 先把数据复制出来

1. 保持只读状态，不要强行改成可读写。
2. 从 NAS 把数据复制到另一块盘或另一台机器：可以用 SMB、NFS，也可以在 OMV 的 shell 里用 rsync。先对一个小目录试一次，确认源和目标没有写反：

# 在 OMV 的 shell 里执行；第一个路径是出问题的文件系统（源），第二个是备份盘（目标）
rsync -a --info=progress2 /srv/dev-disk-by-uuid-<出问题的盘的UUID>/<共享文件夹>/ /srv/dev-disk-by-uuid-<备份盘的UUID>/<目标目录>/

3. 先复制最重要、最难重建的数据（照片、文档），再复制可以重新下载的内容。
4. 复制过程中出现大量读错误，说明盘在变坏。这时更合适的做法是用 ddrescue 之类的工具先做整盘镜像，见用救援系统抢救数据。

4. 再决定要不要检查、修复

文件系统检查必须在未挂载的状态下做。OMV 里的卸载按钮会同时删除挂载记录（见磁盘或文件系统不见了），所以更稳妥的做法是用救援系统离线检查。下面是不会修改文件系统的只读检查：

文件系统	只读检查命令
ext4	fsck.ext4 -n /dev/<分区>
XFS	xfs_repair -n /dev/<分区>
Btrfs	btrfs check --readonly /dev/<分区>

-n（或 --readonly）表示只检查、不修改。输出里错误的数量和严重程度，能帮你判断损坏有多大，也是向社区求助时最有用的信息。

真正的修复命令（fsck -y、不带 -n 的 xfs_repair、btrfs check --repair）有风险，本站不提供可以直接复制的版本。Btrfs 的文档也明确建议不要随意使用 --repair。数据已经复制到安全的地方之后，再带着只读检查的输出去求助，见如何有效求助。

5. Btrfs 的特殊情况

Btrfs 在空间耗尽（尤其是元数据空间用完）时，也会出现写入失败甚至变成只读。先看空间：

# 在 OMV 的 shell 里执行（只读）
btrfs filesystem usage /srv/dev-disk-by-uuid-<UUID>

处理方法见Btrfs 维护：scrub、balance 与换盘。

6. 硬件问题处理完之后

线缆、盘或控制器的问题处理之后，文件系统通过了检查，重启一次，OMV 会按 /etc/fstab 重新挂载。重启之后看上去正常，不等于根因已经解决：继续观察 SMART 和内核日志几天。

确认恢复

1. 再执行一次第 1 步里的 findmnt 命令，/srv/ 下各文件系统的选项里不再有 ro。
2. 在一个不重要的共享里写入再删除一个测试文件：

# 在 OMV 的 shell 里执行
touch /srv/dev-disk-by-uuid-<UUID>/<共享文件夹>/.write-test && rm /srv/dev-disk-by-uuid-<UUID>/<共享文件夹>/.write-test

3. 内核日志里没有新的 I/O 错误，SMART 的关键属性不再增长。
4. 备份已经验证过，见恢复演练。

仍未解决

附上：findmnt 的输出、journalctl -k -b 里相关的几十行、smartctl -a /dev/<磁盘> 的输出、只读检查（fsck -n、xfs_repair -n、btrfs check --readonly）的输出，说明文件系统类型，以及是单盘、RAID 还是 Btrfs 多盘。读如何有效求助。

omv-extras 的文档提醒：向社区求助存储问题时，有经验的成员会默认你已经有完整备份，所以他们给出的修复建议可能导致数据丢失。收到修复建议时，先确认自己的数据已经安全。

参考资料

• omv-extras wiki：Utilities, Maintenance and Backup，其中「When things go wrong」一节讲了出问题时的处理和论坛求助的注意事项
• 本站：Btrfs：多盘、快照与数据校验、OMV 的存储模型：从磁盘到共享