Need help recovering LUKS encrypted disk
 

So while checking out some threads I came across Testdisk, unfortunately, I didn't really know what I was doing and wrote some random partitions to the disk. The LUKS headers are still intact but when I mount them there's nothing that was in my original disk. I'm wondering if by writing the random partitions to the disk that I might have overwritten my files that I need.

When my disk was still working I came across an error while updating to Ubuntu 18.04.1 and used gparted to change my sdx5 partition to swap, which was originally my LUKS partition. I'm afraid that might've screwed up my files as well.

Anyway, I'm able to mount my disk, but it's only 83gb (originally 113gb). Now in Testdisk I'm not really sure how to continue. Please help?

PS. This is on Ubuntu. The original partition table was set up when I installed it using FDE, so SDA1 would've been boot, which I have, SDA2, which was my FS, and SDA5, which was LUKS. With testdisk I'm able to see SDA2, which is 113gb, which I would assume to be my FS, but it won't fit with my boot and LUKS partitions.

If you change your partition scheme, you lose your data.

While you can increase the size of a partition (provided there is free space available), and you can shrink the size of a partition (providing you have unused space you can discard), it is very unlikely that a random partition change that was an error or done with no particular knowledge about what the risks were, will put you in a position where you could recover anything.

What can possibly be done is a forensic recovery where you take the disk offline immediately, get a full image of the disk, and then use tools or hire someone to help you recover files.

There are no tools I can recommend. There is a photo recovery software which people use, I tried it once, it found ... something, a very many something's ... but not all that I needed. I had re-imaged a disk and wanted to try and reconstruct too. What I found was that the effort I might put into learning, and also not getting every part of most files, was that it was far too much trouble for my worth, for also day to day data. The loss of any data is bad. Some or most of it is entirely non-recoverable, but some or most of it is sometimes able to be reconstructed. In other words, code I had written ... I had to write it again. Code I had backed up on our server, was my starting point. So I lost a couple of days work. Live and learn.

Sorry. Just my opinion. Others may suggest some data recovery techniques. I'm just saying the one time I tried, it was too much effort for too little return.

If you only changed the partition table without modifying any data, and you remember/backed up/wrote down your original partition details, you just recreate the partition table.

If you also overwrote some data, you are likely to be out of luck, although it depends, of course, which data you overwrote.

Your description is not quite clear, but you mention "swap", which could mean overwritten data, and "sda5", which indicates an extended partition that might occupy blocks anywhere on the disk. You may have overwritten data by modifying your logical partitions.

What I would do, and it seems you have done that partially: If you see the LUKS header, you should be able to figure out where the LUKS partition starts (ask Google, not me). Then create a partition that starts at that location and has the original size of the LUKS partition, or larger. After that, cryptsetup, fsck, mount, and recover as much as you can. Or cryptsetup, then a suitable filesystem debugger.

Of course, this way you could lose other potentially valuable data on that disk. Therefore, first clone the disk to a file or another disk so that you can repeatedly perform destructive tests.

Not true - simply (immediately) reverting to the old structure works fine. It is subsequent actions that puts data at risk.
I would expect you to lose everything (including the LUKS headers), so count yourself lucky. Your entire post is vague and disjointed and impossible (for me) to determine what you did, and when. Was the swap assigned as part of the upgrade, or simply changed when the system was up and running ?.Again this is just confusing the issue - what is "FS" ?. What do the sizes refer to ?. From a liveCD run this and post all the output (change device as appropriate in need)

Edit: :doh: ... too slow typing again

Hi, thanks for the answers guys. I have not physically written anything nor done anything other than change sda5 to swap as I encountered an error while updating and googled a "solution" that was supposed to fix it. I've only changed around the partition tables so far.

@syg00: FS = filesystem.

@berndbausch: I read not to resize the LUKS partition to the left as it might overwrite data, is that correct? Also, unfortunately, I have not saved the original partition table. Just one more thing to remember to do when having your system running well.

@syg00: ubuntu-mate@ubuntu-mate:~$ sudo lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
loop0
squash /rofs
loop1
squash /snap/core
loop2
squash /snap/puls
loop3
squash /snap/soft
loop4
squash /snap/ubun
sda
├─sda1
│ ext2 78569fbf-ea75-4fa0-b3d2-248360e84ec2
└─sda2
crypto 7d2c9f84-813c-4da4-a62f-5cfac9b88b67
sdb
sr0 iso966 Ubuntu-MATE 18.04.1 LTS amd64
2018-07-25-03-37-28-00 /cdrom

Really hoping I can restore my filesystem. I can actually boot into grub and go into recovery mode. Thank you guys very much for the help, and I will research some more...

ubuntu-mate@ubuntu-mate:~$ sudo parted /dev/sda "print free"
Model: SanDisk Cruzer Glide 3.0 (scsi)
Disk /dev/sda: 125GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
32.3kB 1049kB 1016kB Free Space
1 1049kB 512MB 511MB primary ext2
512MB 513MB 1049kB Free Space
2 513MB 515MB 2097kB primary
515MB 125GB 125GB Free Space

I've attached an image of what my sda disk looks like in gparted, really hoping it can be restored.

Your problem is the size of your LUKS partition. When scanning for partitions, testdisk has no way to determine the size of a LUKS partition (there is no size field in the LUKS header), and thus always assumes the minimum possible size of 2 MB, just enough for the LUKS header itself.

Step 1: Make a backup of the LUKS header. If that header is overwritten, your data is lost forever.

Step 2: Enlarge the LUKS partition so that it extends to the end of the disk. I would not trust gparted to do that. Older versions will simply refuse. New versions will "support" that operation by digging through to the underlying filesystem (which currently does not exist) and try to resize that filesystem to match the new partition size. You really, really don't want it to do that. Use a basic partitioning tool like fdisk to delete the existing partition and create a new one starting in the same place.

Ok, thanks for the info. I'll try that when my dd copy is done. I will backup the LUKS header and try what you've suggested.

Now when you say to delete the existing partition which one are you referring to specifically? The LUKS partition or the unnallocated partition? I'm assuming the LUKS partition? So first find the start of the LUKS header, using hexdump I'm assuming, then extend it to the end of the disk.

That unallocated space is just that - not an unallocated "partition", so just ignore it - delete the LUKS partition /dev/sda2. With luck you should be able to just allow fdisk to allocate the new /dev/sda2 using defaults - it should get the start right and will default to the end of the disk. You'll soon know when you try to mount it.

I don't know what you mean by "resizing on the left". I meant modifying the partition table the way svg00 is suggesting - create a partition that starts at the LUKS partition and has the expected size.

It turns out that the LUKS partition is at the end of the disk, at least it seems to be. This means there is no data after the LUKS partition, and you don't risk anything extending the partition until the end.

Remember: By changing primary partitions, all you do is modify the partition table. In the case of a DOS partition table, this is a 64 bytes area at the end of the first 512 bytes block. You don't change anything else on the disk.

I don't think you actually wrote new partitions to your disk. I think you changed a partition from LUKS to swap. If you can open that partition without errors, you can use foremost to carve out any salvageable files. Making a swap partition does not entail much writing. So, the files should still be there.

You just want to open the LUKS volume. You don't need to mount it. The partition device file will be in '/dev/mapper'. You'll need to know that for foremost. Foremost needs to know the header bytes of every file type you want it to search for and recover.

There is a file called called foremost.conf. It requires an entry for each file type you want the program to look for, i.e. jpg, mp4, odt, txt, etc. The format of the file is listed at the end of foremost man page. Make sure you read and understand what you are doing before you start, including taking the disk in question of service, imaging it to another disk (not to a file), and recovering your files from the image disk.

Foremost was written by two special agents of the US Air Force special investigations division. It is very effective, fast and accurate. But it won't preserve file names. Every recovered file will have a number for the name, with the proper extension.

To get the proper header and footer bytes, you can look at any file of a certain type with The first 4 sets of 2 are the header. For the footer, you do the same thing without the count=1. The last 4 sets of 2 are the footer.

But some file types have no unique footer, so you always have to check the footer of several files of that type to determine of the footer bytes are the same. If they're not, then leave them out of the foremost.conf entry for that file type. Footer bytes are optional in the config file. But if a file type has a unique footer, you should include it.

As long as you didn't write to anything except the partition table, there should not be any need to use foremost or any other recovery tool. Once you extend the partition and unlock the LUKS volume, whatever filesysten was there before should be back, intact.

Agree - data recovery is a PITA even when it works.

@syg00: Just to make a confirmation - use fdisk to delete the LUKS partition, and extend it to the end using the default values? When I try mounting it I'm assuming it'll still prompt for a password?

@berndbausch: By resizing to the left I mean resizing to the the beginning of the disk, instead of the end. I read that resizing toward the beginning of the disk/partition can cause overwriting of data.

@AwesomeMachine: Yes, I'm sure I wrote new partitions to the disk, or at least previous partitions that remained from the last time I formatted the disk.

@rknichols: So writing random partitions to my disk using testdisk shouldn't damage any data right?

So so far I've done: sudo fdisk -W auto /dev/sda2, deleted sda2, created a new partition sda2 using defaults, now have sda2 partition till the end of the disk. How do I mount the partition though? When I try to mount it it says bad filesystem type, bad superblock, other error, etc.

I looked up how to mount partitions but I could not find an alternative superblock, and fsck comes up with the same error of it not describing a valid extX filesystem.

If you made only primary partitions (1 through 4), then the only thing written is the primary partition table in the MBR. The rest of the disk is untouched.

What does "file -s /dev/sda*" report now? If you created partition 2 in the same location as before it should be seen as "LUKS encrypted file".

What is the output from "fdisk -l /dev/sda" ?

I'd say this is true, however I fear "subsequent actions". Because I'm seeing a lot about moving left and extending to end. That's all graphical and non-precise because of sliding with the mouse in gparted.

My example/background would be fdisk where I printed the partition data, so it was retained in my command prompt. And just because, not due to some protective process, but because I want to see what's there to confirm I'm on the right disk, and then proceed to delete the partitions and create new ones.

After which I'd write the new table, exit, and then use mkfs and eventually figure out that I'd screwed myself once I tried to use the disk.

Say I detected my error just after exiting fdisk. Well, in my example, I'd have my old partition table, and barring any other possible action, "yes", I'd try to make the partition table re-match what it had before, and cross my fingers. It does sound as if it would work.

1. I've just never been in a position where I detected the error early enough, and doubt I'll ever be.
2. OP here does not have their original partition table exactly, unless they saved a screenshot of the old table.
3. Is there a way to derive a former partition table in any way?

It's got to be pretty close if the LUKS header is being seen at the start of a partition. testdisk finds LUKS headers and locates the start of the partition just fine. It has no way to know the length. It could be a little smarter and assume a length that extends up to the next recognizable signature, but it doesn't do that and assumes 2 MB.

That's what testdisk is for; it does most of the heavy lifting - most of the time. My mantra is that it's only my data that matters. As suggested earlier, defining a partition at least as large as your target (usually filesystem, but luks container in this case) allows you to work "a piece at a time".
Plenty of potential "flies in the ointment", but works for most simple case.

tl;dr - for legacy MBR partition tables, no.

Because it’s not an ext4 filesystem, but an encrypted partition. Neither mount nor fsck know anything about LUKS. Use cryptsetup to create a decrypted device. The command goes like this:

This is from memory; consult the man page for the correct syntax.

Search the net for more info. For example, Archlinux usually has excellent documentation

Oops missed that post from the OP altogether ... :doh:

The cryptsetup will prompt for the passphrase. If that happens, you should have the partition properly aligned. What happens next depends on how things are configured - is it LVM on LUKS for example. Once cryptsetup has run, run "lsblk -f" again to get an idea.

Got in there first, took my chance :D

I just assumed that there would be a filesystem directly on top of the LUKS partition. This is, of course, not at all guaranteed, and it might be LVM or something more complex. lsblk is a good way to check that.

The OP stated that he can open the LUKS volume, but can't see any files. If that's true, he's going to have to carve out the files that were there before.

He can't see any files because the LUKS volume currently consists of the 2 MB LUKS header and nothing else. That LUKS volume can be unlocked just fine, but the decrypted volume will be zero length. There is no filesystem to mount, and nothing from which to "carve out" files. Fix the size problem and the filesystem should be right there.

This always happens when testdisk restores a LUKS partition.

Ooohhh.... Crap....

File -s /dev/sda = DOS/MBR boot sector.

ubuntu-mate@ubuntu-mate:~$ sudo fdisk -l /dev/sda

Disk /dev/sdc: 116.9 GiB, 125460021248 bytes, 245039104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf096a42e

Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 2048 999423 997376 487M 83 Linux
/dev/sdc2 999424 245039103 244039680 116.4G 83 Linux

So I did But it doesn't prompt me for a password, and doesn't return an error either. There's also not a folder named myfs in /dev/mapper.

I also tried it on my other cloned disk and I enter my password, but it comes back with "Reqeusted offset is beyond size of /dev/sdc2", but I'm not done with that disk yet.

Regarding the screenshot: that was after I was done screwing around with testdisk. I think testdisk is finding my LUKS partition fine, so I'm thinking I'll try to restore the partition and try again.

You omitted the "*" in "/dev/sda*", and so did not see the results for the individual partitions.

Looks like the disk is now (or was when the above display was done) /dev/sdc - adjust all device specific commands appropriately.

No, it still comes up with DOS/MBR boot partitions when I try it with the partition number.

BTW, I still have an intact boot partition, would I be able to extract any info for recovering partitions from there?

Right now I'm going to go back to testdisk to see if I can restore the LUKS partition(s) and try again.

@syg00: Ok. I have 2 disks that I cloned when the first one failed.

Please cut and paste the entire output from that "file -s ..." command. Something is very wrong, and the details might give a clue. I suspect that you re-created that LUKS partition with the wrong starting location, perhaps at a spot that used to be the beginning of a DOS/Windows FAT partition.

You may need to use testdisk to locate that start of that LUKS container again.

Ok, thanks very much for helping btw. Luckily I still have a copy of that drive.

BTW, when using Testdisk I come up with 2 LUKS partitions which I wrote to one of my disks. I'm assuming partition 1 is the one I should be keeping? I'm running Testdisk on it right now and will edit my post when I have their locations.

Actually I can find them with gparted. Partition 1 starts at sector 1001472, and partition 2 starts at 79020032.

I will have the file -s info when I redo the deleting and reconstructing of the partitions.

My best guess at this point is that each of those LUKS partitions should be extended to include the free space that follows it. I have no way to know which is the one you want to keep. Be sure that the reconstructed partitions start at those exact sector numbers, and do not use a tool that tries to reformat them.

[EDIT] Looking back at your original post where you said the partition size was 113 GB, that suggests that partition 1 should extend to the end of the disk and partition 2 should be deleted. What testdisk found as a possible second partition could be just a leftover LUKS header from a previous use of the drive, a sector that was never overwritten in the current arrangement. To confirm that, you could extend partiton 1 to include just the 40 GB that follows and then see if fsck complains that the volume is too small for the filesystem.

Ok, awesome. Now when I deleted the partitions and started from the LUKS sector and recreated the partition, it now shows up as a LUKS partition. Just in case it might help anyone else I looked up the starting sector location in gparted.

I'm guessing since the boot partition was deleted as well, and starting from the beginning of the disk at sector 2048 was why it was reading as the boot partition. I guess I was told to start at the starting sector at the LUKS partition as well though... So my bad.

However, when I try to mount it using cryptsetup - it prompts for the password, but when I type the password, it returns: "no key available for this passphrase". I'm pretty sure I'm entering the password correctly because I used the same password before to unlock and auto-mount the previous failed partitions, that was on the GUI though. I'm not sure why it's not working with cryptsetup.

That unfortunately suggests that the key material in the LUKS header might have been partially overwritten. What tool did you use to make the resized partition? Some versions of gparted have been known to write a garbage sector in the area where LUKS key material for the first key slot is stored. Did you make a backup of that LUKS header? It should be a ~1 MB or ~2 MB file, depending on the key size.

There is a tool that checks for damaged key slots. Is just looks for "non-random looking" data in the key material. For some reason it is not normally compiled and installed, but exists only in the source code for cryptsetup-1.6.0 and later versions. It's mentioned briefly in the Cryptsetup FAQ, but it's been a long time since I tried to build or use it. The output from "cryptsetup luksDump" shows the "Key material offset" (in 512-byte sectors) where that "random-looking" material should start. If you look with at hex editor and see anything that looks decidedly non-random there or in the next few sectors (the key material actually goes on for far more sectors than you would care to look), you know you have a problem.

Ok, after restoring the LUKS header, and again entering the right password, it finally works, however, it now outputs: "Cannot use device /dev/sda2 which is already in use (already mapped or mounted)". I used the command Holy crap... so after that error, I had another cloned disk, so I restored the LUKS header to that disk as well, and now I have "myfs" and "ubuntu-gnome-vg-root" under /dev/mapper. What should I do now?

After looking around, I found /dev/ubuntu-gnome-vg/root in gnome disks and mounted it, says structure needs cleaning.

Now it seems that LVM is involved. Since I'm not looking over your shoulder, I'm a bit lost as to what is where and the filesystem(s) involved. With the LUKS container(s) unlocked, please run "lsblk -f" and post the output.

Sorry, looks like things got a little cut off there. Is that good enough?

Good enough. Apparently the system was happy with the ubuntu-gnome-vg-root logical volume fitting within the sdd2 partition and found the ext4 filesystem within. Since you do have a backup of all this, running "fsck -fy /dev/mapper/ubuntu--gnome--vg-root" should clean up the filesystem so that it can be mounted.

Ok, so I ran the command. How do I mount the filesystem? When I try to mount "myfs" I get "unknown filesystem type 'LVM2_member'".

I looked it up and found the command: It mounted, but I wasn't able to find anything I was trying to find, the /home folder was empty, etc. Starting to wonder if this was a fruitless endeavor.

Did you run the "fsck -fy /dev/mapper/ubuntu--gnome--vg-root" command I suggested? I'd also like to see the output from the "vgs" and "lvs" commands.

Perhaps the /home directory in that root filesystem is just a mount point for another volume. Does the /etc/fstab in that filesystem show anything for /home?

I'll check once I'm back home but yes I did run the command.

sudo vgs:

sudo lvs:

Weird, but now the "udisks" command is not working anymore. Is that the correct way to mount the filesystem?

Well that's the problem, or at least one problem. Your partition is 607 MiB too small (1243136 sectors). You need to adjust the partition table again.

What did fsck report when you ran it? I would be surprised if it didn't detect the size problem and refuse to run.

Regarding udisks, I've never used it, and the Ubuntu-16.04 I have available doesn't have it available. I just use the mount command directly (as root).

Hmm.... Ok.

So I repartitioned the disk and ran "sudo vgs/lvs" commands again, no complains. However, I mounted the disk via gnome disks, and again, nothing in the /home folder.

Ran fsck on "/dev/mapper/ubuntu--gnome--vg-root" and it came back clean.

I will try this with my second disk.

BTW, nothing was mapped to my /home folder in fstab. So weird, because I'm positive this is the disk I was using.

By any chance, have you looked in the lost+found directory in that filesystem?

What does the disk partitioning look like now? Is there still any large block of unallocated space?

It really doesn't make any sense that the filesystem would come back with no errors but with an empty /home if that's where your data had been. That sort of thing "just doesn't happen".

It does if something else was mounted to /home. And yes, I saw the comment about nothing being in fstab for /home. In truth, with the root that big I wouldn't expect a separate lv for /home. Very odd.

There aren't any unallocated spaces except for a small space before the encrypted partition.

I havent looked in the lost+found directory, where would that be found?

@syg00: what does it mean for something else to be mounted to /home?

Ugh... this sucks...

It is common to have a separate partition created for /home. For this to be accessed the separate partition has to be "mounted" - /home is then the mount-point, and all sub-directories (like Documents say) can then be referenced. The mount is usually automated by an entry in /etc/fstab.
This separate partition (or lv) can be on the same disk, or another, it matters not.

Would that be something a user would set up themselves, or an automated process during installation?

Mine was just a regular install so I don't get why the /home folder wouldn't be there.

The lost+found directory is in that same filesystem, at the same level where you see the home directory. If you have that filesystem mounted on /media/xxx, then it would be /media/xxx/lost+found.

A separate /home is a common configuration, but never by default AFAIK. I don't think you actually used a totally default configuration, though, since LVM and encryption are options that have to be specifically selected in the Ubuntu installer. You wouldn't get a separate /home, though, without selecting "Something else" in the storage allocator and manually configuring partitions or LVs.

Well, yeah, default except for the full-disk encryption.

I'll try and see if my other cloned disk yields anything.

So on my other disk I ran "sudo vgs" again, and it again complains that "Device /dev/mapper/myfs" is smaller than the PV size. I repartitioned, and there's only 1MB left before the encrypted partition, could this be what's causing the problem? When I try to include that 1MB, it's no longer an encrypted partition.

The partition must start at the exact sector with the LUKS header. I noticed that when one asks for encryption + LVM, the Ubuntu installer actually creates an extended partition and creates a logical partition (partition 5) for the LUKS volume. Satisfying alignment constraints requires a small space ahead of that logical partition. Making that partrition a primary partition would mean that your recovered system might not boot (or might boot just fine -- depends on how the volumes are referenced), but in no way should affect the content of that filesystem.

Ok, got it.

So I just re-did everything again, deleted partitions, recreate, etc. luksOpen'ed the partition and tried to run "fsck" on "/dev/mapper/ubuntu--gnome--vg-root" and came back with this:

Ok, nevermind. I rebooted and ran it again and came out with:

Damnit... I mounted it and again, nothing in the /home directory. Is this just a complete loss?

Was that with the enlarged (245276672 sectors) partition? What do vgs and lvs report now?