在 Linux 服务器上创建文件、写日志或更新程序时，如果命令返回 Read-only file system，问题通常不在目录权限。即使使用 root，只读挂载的文件系统也不会接受普通写入。
这类故障有两种常见情况：一种是分区、云硬盘或容器目录原本就以只读方式挂载；另一种更需要警惕，内核检测到文件系统或底层存储异常后，为了减少进一步损坏，将文件系统重新挂载为只读。两者的处理方式不同。不要看到报错就直接执行 mount -o remount,rw，先保留日志并确认只读的原因。
一、先确认报错是不是“文件系统只读”
先在报错目录创建一个临时文件：
touch /故障目录/.write-test如果返回：
touch: cannot touch '/故障目录/.write-test': Read-only file system说明内核认为该路径所在的挂载点不可写。它与 Permission denied 不是一回事。权限拒绝通常要检查用户、属主、权限位、ACL 或 SELinux；文件系统只读应先检查挂载选项、文件系统状态和底层存储。
使用 findmnt 定位目标路径对应的设备、文件系统类型和挂载参数：
findmnt -T /故障目录 -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f记录挂载点、设备名、文件系统类型，以及 OPTIONS 中是否出现 ro。如果显示 rw，但写入仍报只读，需要检查该路径是不是容器只读挂载、网络存储或特殊文件系统。
二、判断是主动只读，还是故障后被重新挂载
查看当前挂载状态
findmnt -T /故障目录
mount | grep ' /故障挂载点 '常见结果包括：
ro：当前以只读方式挂载；rw：文件系统记录为可读写，需要继续检查具体路径和上层挂载；errors=remount-ro：Ext4 遇到错误时可重新挂载为只读，这个参数本身不等于当前已经发生故障。
立即查看内核日志
如果服务器原来可以正常写入，后来突然变成只读，内核日志比反复重启更有价值：
journalctl -k -b --no-pager | grep -iE \
'I/O error|buffer I/O|read-only|remount|ext4-fs error|xfs.*error|blk_update_request|nvme|scsi'系统没有持久化 journal 时，可以查看 dmesg：
dmesg -T | grep -iE \
'I/O error|buffer I/O|read-only|remount|ext4-fs error|xfs.*error|blk_update_request|nvme|scsi'如果看到 EXT4-fs error、Buffer I/O error、NVMe reset、SCSI error 或设备离线等记录，应按存储故障处理。文件系统只读可能只是保护结果，底层硬盘、云盘链路或宿主机存储才是起因。
保存现场信息
在仍能读取数据时，先把必要信息保存到其他正常磁盘或远程位置：
findmnt -T /故障目录
lsblk -f
journalctl -k -b --no-pager生产服务器还应记录最近的重启、扩容、快照恢复、磁盘迁移、内核升级和异常关机时间。不要把日志继续写回故障分区。
三、先处理最容易确认的配置问题
检查 /etc/fstab
查看对应分区是否被配置为只读：
grep -vE '^\s*#|^\s*$' /etc/fstab检查挂载选项中是否误写了 ro，UUID 是否指向错误设备，或者恢复快照后设备关系是否发生变化。修改前先备份：
cp -a /etc/fstab /etc/fstab.bak.$(date +%F-%H%M%S)修改后可以先检查语法和挂载关系：
findmnt --verify --verbose不要在没有控制台或救援入口的远程服务器上贸然修改根分区配置。fstab 写错可能导致下次启动进入紧急模式。
检查是否挂载了快照或只读卷
云平台快照、恢复盘、某些备份卷和存储副本可能只允许读取。此时操作系统里的 remount,rw 不一定能改变云平台侧的属性。
检查设备来源后，再到云平台控制台确认：
- 云硬盘是否正常挂载到当前实例；
- 是否使用了只读共享或快照视图；
- 磁盘是否处于异常、迁移或恢复状态；
- 最近是否发生强制卸载、实例迁移或存储告警。
检查容器只读挂载
如果只有容器内报错，而宿主机可以写入，查看容器的挂载配置：
docker inspect 容器名或ID重点检查 ReadonlyRootfs，以及 Mounts 中的 RW、Mode 字段。Compose 中的 :ro、Kubernetes 的 readOnly: true，都会让容器看到只读目录。此类配置应在编排文件中修正并重新创建容器，不要在容器内部强行改挂载参数。
四、什么时候可以尝试重新挂载为可写
只有在下面这些情况同时成立时，才适合做一次受控验证：
- 已确认没有持续出现 I/O 错误；
- 只读来自错误的挂载参数、维护操作或明确的临时配置；
- 重要数据已经备份；
- 有控制台、救援模式或回滚方案。
执行：
mount -o remount,rw /故障挂载点然后立即验证：
findmnt -T /故障挂载点 -o TARGET,SOURCE,FSTYPE,OPTIONS
touch /故障挂载点/.write-test && rm -f /故障挂载点/.write-test如果重新挂载失败，或者很快再次变成只读，不要循环执行 remount。继续写入可能扩大损坏，应转入离线检查和数据保护流程。
五、检查磁盘或NVMe健康状态
物理机或能够透传 SMART 信息的环境，可以使用 smartctl：
smartctl -a /dev/sdaNVMe 设备可以查看健康日志：
nvme smart-log /dev/nvme0需要关注介质错误、不可恢复错误、重新分配扇区、CRC 错误、异常掉电和温度等信息。不同厂商对属性的定义并不完全相同，不能只凭某一项原始值下结论。
在云服务器中，虚拟磁盘通常不会完整暴露物理盘 SMART 数据。应同时查看云平台事件、磁盘监控和实例宿主机告警；怀疑底层存储异常时，尽快创建可用快照或备份，并联系云服务商核查。
六、Ext4文件系统如何离线检查和修复
e2fsck 不应对已经挂载的 Ext2、Ext3、Ext4 文件系统执行修复。数据盘应先停止使用它的应用，再卸载：
systemctl stop 相关服务
umount /故障挂载点确认已经卸载：
findmnt /故障挂载点再执行检查与修复：
e2fsck -f /dev/对应设备设备名必须以 findmnt、lsblk -f 的结果为准，不能照抄示例。对根分区操作时，应从云平台救援模式、安装介质或其他系统启动，确保目标文件系统未挂载。
修复完成后重新挂载并检查：
mount /故障挂载点
findmnt -T /故障挂载点
journalctl -k -b --no-pager | tail -n 100如果 e2fsck 反复发现新错误，优先怀疑存储设备、内存、控制器或宿主机链路，不要把定期跑 fsck 当作长期方案。
七、XFS文件系统不要直接套用fsck命令
XFS 的检查和修复工具是 xfs_repair。先停止业务并卸载目标文件系统，再做只读检查：
xfs_repair -n /dev/对应设备确认维护窗口和备份后执行修复：
xfs_repair /dev/对应设备xfs_repair -L 会清空日志，可能丢失尚未落盘的元数据更新，只能作为最后手段。执行前应阅读命令输出和官方文档，保留快照或块级备份，并确认普通修复为什么无法继续。
八、根分区变成只读时怎么处理
根分区只读后，日志、数据库、包管理器和许多服务都会停止写入。稳妥的顺序是：
- 通过云控制台或带外管理保留当前错误信息；
- 停止继续产生大量写操作的业务；
- 把可读取的重要数据复制到其他磁盘或远程位置；
- 创建云盘快照或块级备份；
- 进入救援系统，确认根分区没有挂载；
- 根据 Ext4 或 XFS 类型使用对应工具检查；
- 修复后启动系统，持续观察内核日志和磁盘状态。
如果系统已经无法稳定读取，备份工具频繁报 I/O 错误，应减少反复扫描。重要数据场景下，先克隆故障盘或交给专业数据恢复流程，比在原盘上多次修复更稳妥。
九、常见误区
直接执行chmod 777
权限位不能改变文件系统的只读状态。chmod 本身也需要写入元数据，通常会同样报错。
不看日志就强制remount为rw
如果只读是内核对文件系统错误的保护，恢复写入可能让损坏继续扩大。先看内核日志，再决定是否 remount。
对已挂载分区运行fsck
文件系统仍在变化时执行修复，可能造成不可预测的结果。数据盘要卸载，根分区要进入救援环境。
把XFS当成Ext4修复
XFS 使用 xfs_repair，Ext4 使用 e2fsck。先用 findmnt 或 lsblk -f 确认类型。
修好文件系统就不再检查硬盘
文件系统错误可能由异常断电引起，也可能由硬盘、控制器或云存储链路故障引起。修复文件系统后仍需观察设备健康、内核日志和云平台告警。
十、一套可直接执行的排查顺序
# 1. 定位路径对应的挂载点、设备和文件系统
findmnt -T /故障目录 -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f
# 2. 查看本次启动的内核错误
journalctl -k -b --no-pager | grep -iE \
'I/O error|buffer I/O|read-only|remount|ext4-fs error|xfs.*error|nvme|scsi'
# 3. 检查静态挂载配置
grep -vE '^\s*#|^\s*$' /etc/fstab
findmnt --verify --verbose
# 4. 有明确证据证明只是挂载参数错误时，才受控验证
mount -o remount,rw /故障挂载点如果日志中出现文件系统或设备错误，停止在生产系统里继续试写。备份数据，卸载文件系统，并按 Ext4 或 XFS 的正确工具进入离线检查流程。
常见问题
重启服务器能恢复吗？
配置错误可能在重启后暂时恢复，也可能因为 /etc/fstab 再次以只读方式挂载。文件系统或磁盘错误导致的只读，重启并不能消除根因，还可能丢失现场日志。
remount成功后是不是就修好了？
不是。remount 只改变当前挂载状态。内核日志如果存在 I/O 或文件系统错误，仍要备份、离线检查并确认底层存储健康。
可以在线修复根分区吗？
不建议在正常运行且已挂载的根分区上执行 e2fsck 或 xfs_repair。使用云平台救援模式、安装介质或其他系统启动后再处理。
云服务器看不到SMART信息怎么办？
查看云平台磁盘监控、实例事件和告警，先创建可用快照或备份，再联系服务商核查底层存储。虚拟磁盘不一定暴露物理盘健康数据。
参考资料
- Linux man-pages：mount(8) – 挂载与重新挂载选项
- Linux man-pages：fsck(8) 与 e2fsck(8) – 文件系统检查说明
- Linux man-pages：xfs_repair(8) – XFS 检查与修复参数
- Linux Kernel Documentation：Ext4 文件系统文档
- Smartmontools：smartctl 官方手册
核验日期：2026年8月26日