![我可以通过 ext4 LUKS 分区中的 inode 打开文件吗?](https://linux22.com/image/1634642/%E6%88%91%E5%8F%AF%E4%BB%A5%E9%80%9A%E8%BF%87%20ext4%20LUKS%20%E5%88%86%E5%8C%BA%E4%B8%AD%E7%9A%84%20inode%20%E6%89%93%E5%BC%80%E6%96%87%E4%BB%B6%E5%90%97%EF%BC%9F.png)
我有一个ext4 LUKS我“删除”了一个文件的分区。(我将一个文件移到了另一个分区:mv /media/HDD/file1.txt /media/HDD/file2.txt
file1.txt 和 file2.txt 都已经存在)。
目录中的文件具有连续的 inode 编号,因此我可以猜测我丢失的那个ls -il
,我们称之为 12345678。
我尝试find -inum 12345678 -exec gedit {} \;
打开它(它可以处理其余文件),但由于它只在目录中搜索,所以无法处理我丢失的文件。
我试过调试文件系统(先解锁udisksctl unlock -b /dev/sdb
:)像这样:
~$sudo debugfs /dev/sdb
debugfs 1.45.5 (07-Jan-2020)
debugfs: Bad magic number in super-block while trying to open /dev/sdb
/dev/sdb contains a crypto_LUKS file system
debugfs:
如果不解锁分区,也会发生同样的情况。
为什么显示“错误的魔法数字”?我该如何打开文件?还有其他方法可以恢复我的文件吗?
我正在运行 Ubuntu 20.04。
答案1
我尝试了 debugfs(首先解锁:udisksctl unlock -b /dev/sdb),如下所示:[…]
如果不解锁分区,也会发生同样的情况。为什么会显示“错误的魔法数字”?
LUKS 不会改变 ext4 的工作方式。但是,它改变了 ext4是。
锁定/解锁卷的工作方式与切换开关不同,它的工作方式与打开/关闭容器相同。也就是说,当您“解锁” LUKS 卷时,这不会以任何方式更改原始分区 - 如果 /dev/sda1 之前包含加密的 LUKS 数据,则之后它仍将包含加密的 LUKS 数据,即不是ext4。
相反,纯文本 ext4 文件系统必须通过新的设备,通常是/dev/mapper/luks-something
,通过 LUKS 加密/解密过滤读取或写入的数据。因此正确的命令类似于:
sudo debugfs /dev/mapper/luks-whatever
(除此之外,/dev/sdb 不是一个分区 - 它是整个磁盘。它的分区会有名为 /dev/sdb1、/dev/sdb2 等的设备。在整个磁盘上直接安装 LUKS 和/或 ext4 是相对正常的,但这并不会将其变成一个分区。)
还有其他方法可以恢复我的文件吗?
这Arch Linux 维基推荐该ext4magic
工具。
较旧的extundelete
工具可能也可以工作,尽管它已经过时并且不适用于使用元数据校验和的 ext4 文件系统。
因为你的 ext4 文件系统在 LUKS 里面,全部这些工具需要在“udisksctl unlock”创建的“映射器”设备上运行 - 而不是在原始磁盘上运行。