Linux 硬盘挂载为只读（RO）且无法重新挂载为读写（RW）的解决方案

问题背景

服务器配置如下：

• /dev/vda1：系统盘。
• /dev/vdb1：一个独立的云磁盘，挂载到 /home/wwwroot 目录，用于存放网站数据。

最初，网站数据存放在系统盘的 /home/wwwroot 目录。购买新云盘后，将原目录重命名为 /home/wwwrootB，新建 /home/wwwroot 目录，并将格式化后的新磁盘挂载于此。

系统运行一直正常，直到某天，服务器上一个基于 DedeCMS 的网站后台无法创建新栏目。通过 SSH 登录服务器检查，目录权限设置正常。同一磁盘上的 WordPress 站点却运行正常，可以上传图片和发布文章。

问题排查过程

1. 初步怀疑与权限限制

起初怀疑是 LNMP 环境中的跨站保护机制（如 .user.ini 文件的不可变属性）导致。尝试使用以下命令移除该属性：

chattr -i /.user.ini

系统返回错误：

Read-only file system while setting flags on ./.user.ini

这表明文件系统本身可能处于只读状态。

2. 检查文件系统挂载状态

使用以下命令查看当前所有挂载点的详细信息：

cat /proc/mounts

关键输出如下：

/dev/vdb1 /home/wwwroot ext4 ro,relatime,barrier=1,data=ordered 0 0

可以看到，挂载在 /home/wwwroot 的磁盘 /dev/vdb1 属性为 ro（只读）。

3. 尝试重新挂载为读写模式

尝试使用以下命令将其重新挂载为读写（rw）模式：

mount -o remount,rw /home/wwwroot

操作失败，系统提示：

cannot remount block device /dev/vdb1 read-write, is write-protected

4. 深入检查系统日志

使用 dmesg 命令查看内核日志，发现了大量与文件系统相关的错误信息：

EXT4-fs error (device vdb1): ext4_journal_start_sb: Detected aborted journal
EXT4-fs (vdb1): Remounting filesystem read-only
JBD: Spotted dirty metadata buffer (dev = vdb1, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
EXT4-fs error (device vdb1) in ext4_orphan_add: Journal has aborted
...（后续为类似错误）

日志明确指出，文件系统（/dev/vdb1）的日志（journal）已异常中止，内核因此自动将其重新挂载为只读模式，以防止数据损坏。这是典型的文件系统错误迹象。

5. 尝试修复文件系统

首先，非常重要的一步是停止所有相关服务（如 LNMP），以避免在修复过程中对文件系统进行写操作，导致进一步损坏。

lnmp stop

然后，尝试使用文件系统检查修复工具：

fsck -y /dev/vdb1

但命令可能失败，并提示设备已被挂载：

fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
/dev/vdb1 is mounted.
e2fsck: Cannot continue, aborting.

这表明需要在卸载（umount）文件系统后才能进行修复。但在只读状态下，卸载操作通常是允许的。

根本原因与最终解决方案

根据日志分析和常见情况，根本原因在于文件系统（Ext4）的日志系统出现了严重错误，触发了内核的保护机制，强制将其设置为只读。

标准解决步骤：

1. 卸载文件系统：

   umount /dev/vdb1

   如果因“设备忙”无法卸载，需使用 lsof 或 fuser 命令找出并结束占用进程。

2. 强制检查并修复文件系统：

   fsck -yf /dev/vdb1

   参数 -y 表示自动回答“yes”，-f 表示强制检查即使文件系统看起来干净。此过程可能会修复损坏的日志和元数据。

3. 重新挂载：修复完成后，重新挂载文件系统。

   mount /dev/vdb1 /home/wwwroot

   此时应能正常挂载为读写（rw）模式。可通过 mount | grep vdb1 或 cat /proc/mounts 确认。

4. 重启服务：确认挂载正常后，重启之前停止的服务。

   lnmp start

极端情况处理：如果 fsck 修复失败，或修复后问题依旧，可能意味着文件系统损坏过于严重。此时，最后的办法是：

1. 备份数据（如果可能，从其他备份源恢复）。
2. 重新格式化磁盘：

   mkfs.ext4 /dev/vdb1

   警告：此操作会清除该磁盘所有数据。

3. 重新挂载并恢复数据。

原文中提到的“还要再格式化一次,再mount”正是应对这种严重损坏的最终手段。在日常运维中，应优先尝试 fsck 修复，并确保有定期备份策略。