1

I originally set up a 12Tb external hard drive making it encrypted with luks2. I used it fine for a couple years. For whatever reason I wanted to decrypt it the other week so I got the latest cryptsetup and ran the following to decrypt in place

./cryptsetup reencrypt --decrypt --header ~/important/seagate-12tb-exported-header.bin /dev/sdb3

That header file wasn't detached so I believed it was going to decrypt the data in line according to the man pages. (Note the cryptsetup I had was v2.7.5)

Somewhere in the middle of that decryption I decided that decrypting wasn't the right solution to my problem so I hit ctrl+c and stopped decrypting (or so I thought?).

Anyways today I checked the device and it wasn't a luks device. (My server was on the whole time). However the data was still showing at the mount point. I got confused, assumed the decryption had continued (it was started in a tmux session), and so I decided, I guess its fine that it got decrypted. I removed my /etc/cryptab and /etc/fstab entries and rebooted my computer. After rebooting, the data wasn't at the mount point as expected since removing from /etc/fstab. I tried mounting and got an error as listed below. Have I lost my data? How can I recover it if I can? The filesystem was supposed to be ext4 and the device was /dev/sdb3. I do have exported luksHeaders but I'm not sure if this is a luks encrypted anymore?

$ sudo mount /dev/sdb3 /mnt/storage mount: /mnt/storage: wrong fs type, bad option, bad superblock on /dev/sdb3, missing codepage or helper program, or other error. $ lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS <truncated> sdb |-sdb1 vfat FAT32 EFI 67E3-17ED |-sdb2 apfs 91c4ccef-ebf2-4976-8c93-93d48340022b `-sdb3 $ fdisk -l <truncated> Disk /dev/sdb: 10.91 TiB, 12000138624512 bytes, 23437770751 sectors Disk model: Expansion Desk Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: FBCE93CD-E379-437C-9E78-20049E50D514 Device Start End Sectors Size Type /dev/sdb1 40 409639 409600 200M EFI System /dev/sdb2 409640 976972135 976562496 465.7G Apple APFS /dev/sdb3 976972136 23437770711 22460798576 10.5T Linux filesystem
Improve this question

1 Answer 1

Reset to default
1

You should not attempt to mount /dev/sdb3 directly, as doing so might damage data. If you do not have backups, this would be a good time to make a full copy of your drives and headers.

Re-encryption (or decryption) re-writes all data on disk, which is a process that takes many hours (depending on device size and speed). If you Ctrl-C, you end up with a device that is partially decrypted, partially encrypted.

To recover, you need the header, in your case presumably ~/important/seagate-12tb-exported-header.bin. Check cryptsetup luksDump for this header; it should mention things about reencrypt and (in case of decryption) show data segments of type linear.

If everything is in order, opening the device using this header should work.

# cryptsetup open --header yourheader.bin /dev/yourdevice cryptname

Note: Device names can change so make extra sure, that /dev/sdb3 is still /dev/sdb3 before you run this. Do not try to open the wrong device with an external header.

If that works and you then wish to resume the operation, you can trigger it with another reencrypt:

# cryptsetup reencrypt --header yourheader.bin /dev/mapper/cryptname WARNING! ======== Device … is already in LUKS2 reencryption. Do you wish to resume previously initialised operation? Are you sure? (Type 'yes' in capital letters):

However consider making backups as soon as you have access to your data. In-place conversions are always a bit risky.

If the header is lost and no other header backups exist, you will not be able to recover anything that remains encrypted; and the filesystem itself will most likely be fubar.

In theory it's also possible to recover with an old header backup (re-encryption progress lost) but it's a lot more complicated. And most people don't have such header backups either.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.