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 ...

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

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.

Attached Thumbnails

 

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.