LUKS分区挂载为只读

Question

系统日志提取显示这不是 LUKS 加密的问题，而是加密分区上未锁定的 EXT4 文件系统的“使用”问题：在过去的某个时刻，发生了文件系统不一致的情况，例如由于它被删除未正确卸载、断电或任何其他原因。当文件系统驱动程序尝试启动该错误时，会注意到该错误杂志文件系统的

引用：

ext4_clear_journal_err:6017: Filesystem error recorded from previous mount: IO failure

这意味着文件系统处于“坏”状态，需要修复。

引用：

warning: mounting fs with errors, running e2fsck is recommended

目前，文件系统已挂载，但建议执行文件系统检查。建议不要在该状态下对文件系统执行任何写入操作。

最终，内核注意到文件系统结构中存在进一步的不一致

EXT4-fs error (device dm-3): ext4_validate_block_bitmap:390: comm ext4lazyinit: bg 3999: bad block bitmap checksum

因此，内核决定将其挂载为只读，以便您可以访问文件，但不执行任何可能加剧内部不一致的进一步修改（达到实际上可能损坏的程度）。您可以从时间戳中看到，这需要一些时间才能发生，因此当您实际执行操作时可能会有很短的时间窗口能（但仍然不应该）写入分区。

为了解决这个问题，您应该按照文件系统驱动程序的建议进行操作：

对加密分区上的所有数据执行备份- 毕竟它仍然是可读的。
识别 LUKS 暴露的原始设备。您可以通过调用来做到这一点lsblk；解锁的 LUKS 分区将显示为类型的设备crypt：
```
~$ sudo lsblk
NAME             MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
...
sdb               ..:..  ... ...  .. disk
+- sdb1           ..:..  ... ...  .. part
   +- some_name   ..:..  ... ...  .. crypt /path/to/mountpoint
```
在这里，所有这些...都是实际但变化的值的占位符。相关点是，在示例中，到加密原始设备的解锁映射是/dev/mapper/some_nome，并且它安装在上/path/to/mountpoint。
卸载文件系统，但不重新锁定 LUKS 分区。这需要“手动”完成，因为使用文件管理器提供的“弹出”功能通常会重新锁定同一进程中的分区。确保没有进程访问加密分区上的文件或目录，然后执行
```
~$ sudo umount /path/to/mountpoint
```
对未锁定的加密分区上的文件系统执行文件系统检查
```
~$ sudo e2fsck -v /dev/mapper/some_name
```
您可能会收到大量错误消息，并被询问是否要执行一些建议的修复。确切的问题取决于不一致的性质；您需要咨询您最喜欢的搜索引擎来了解其含义，并确定这是否是一个好主意。

操作完成后，可以再次挂载该分区：

~$ sudo mount /dev/mapper/some_name /path/to/mountpoint

Answer 1