My luks encrypted image unlocks but fails to mount

Question

I have a LUKS image which I decrypt, mount and save important documents to. Until recently, this was running fine, on an Ubuntu 19 machine. I shut this machine down, while the image was mounted, believing this would be fine. I have rebuilt a new fileserver with different hardware and MX Linux. I attempted to mount the image again. I unlocked the image file but could not mount it.

The image file was created as follows:

dd if=/dev/zero of=s9_vault.img bs=1M count=4096
sudo cryptsetup -y luksFormat s9_vault.img 
sudo cryptsetup luksOpen s9_vault.img s9_vault
sudo mkfs.ext4 /dev/mapper/s9_vault

Now I have my new file-server, I start with the following command:

sudo cryptsetup luksOpen s9_vault.img s9_vault

Key slot 0 unlocked.
Command successful.

No errors are reported so it seems that the image has decrypted correctly. I move on to mounting:

sudo mount /dev/mapper/s9vault temp

This fails with the following error message:

mount: /home/XXX/temp: wrong fs type, bad option, bad superblock on /dev/mapper/s9vault, missing codepage or helper program, or other error.

I have tried to fix the superblock with fsck:

sudo fsck /dev/mapper/s9vault
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/mapper/s9vault

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

So I took a look with mke2fs:

sudo mke2fs -n /dev/mapper/s9vault
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 1044480 4k blocks and 261120 inodes
Filesystem UUID: 6be51418-5a91-40b9-84aa-1459bb6f5a40
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736

I have tried every superblock suggested in this list but this error message keeps occurring.

sudo e2fsck -b 32768 /dev/mapper/s9vault 
e2fsck 1.44.5 (15-Dec-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/s9vault

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

I have tried the programs scalpel and photorec to see if they can pick anything up. Neither report any files which is quite odd.

Is it possible that the unencrypted image was broken in such a way that luks can still decrypt but is essentially decrypting a mess into another mess? I've looked at the decrypted image in a hex editor and it seems mostly random.

Cheers

B

Additional. I have a backup that uses rsync to copy files from one disk to another which includes this image. I tried using the backup copy and got the same error. Wondering if this is something peculiar about the computer im using. The machine that first made and mounted this image has been gotten rid of and a new one put in it's place with the disks and data from the old machine.

Answer 1

First let's find where your superblock backups are kept.

# mke2fs -n /dev/mapper/s9vault

Down at the bottom of this output, should be a list of the backups.

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Finally, restore the superblock from the backup, replacing block_number with the first superblock backup.

# e2fsck -b block_number /dev/mapper/s9vault

Now try to mount the filesystem, and your superblock should be fixed. If it’s not, repeat the steps, but restore a different superblock backup.

Answer 2

My guess is that "something bad" happened in the time between creating the ext4 filesystem on the LUKS device and trying to re-use it. For example if something wrote unencrypted on the device while leaving the LUKS header intact, this could be the result.