I have changed the top portion of this post because possibly my issue is different than described below. Specifically, it seems as if my LUKS volume "is" currently mounted and open, albeit through my install thumbdrive. This is after a reboot w/ my KDE neon thumbdrive.

My issue may be that I have just not found the appropriate commands to access it (showing hidden, tried Dolphin, Caja & Thundar). All "dolphin path" choices I have tried result in empty finder windows - whether I use mapper as part of the path or not. If I select in a finder the icon for a "222.4 GiB Encrypted Drive" I get this error message:
So far that hasn't helped me find a solution to open the volume.

I repeated the earlier requested commands and got this variance:

It no longer indicated that sda3_crypt already exists and the echo $? returned a 0 instead of 5 (I don't know what that signifies, but it is different).


Doesn't this indicate that it is open?

Plus GParted states that it is "Active" and "Open".



If someone can suggest a method that will enable me to open this in a finder window so I can move files to a new location off the SSD I would actually be done.

But I also realize it might not be this simple.

BTW, as previously, I cannot log into my SSD as usual, it simply takes me to GRUB2.02 and I cannot restore using Timeshift.





=============================================================================================
=============================================================================================

I am seeking help in recovering the contents of a LUKS volume on a KDE Neon kept up to date on a 230GB SSD.

The EVENT happened the evening of the 4th of June, when I was creating a different OS on a thumbdrive. At the point where you choose where to install, I chose the appropriate sd and moved to the next step but it did not have the LVM I wanted so I clicked back to choose again, I chose LVM w LUKS and started the install, but in one second or less I noticed and clicked Back again - because it had reset to my sda drive and I hadn't noticed prior to begining the install. So in one second or less I tried to stop the process and it took a few seconds before it went back to where to choose to install -- I chose the correct sd and created a successful bootable thumbdrive of another OS. That is when the EVENT happened.

Does my description of what happened suggest to you that more than the LUKS header was damaged, it and the GRUB2 files; OR is it truly unrecoverable and I need to try to re-create several months of work from scratch?

Upon booting back to Neon, all I got was the GRUB 2.02 screen, Exit-ing didn't do anything. End of the day. The next morning I had a recent KDE Neon thunbdrive available and installed Timeshift on it and attempted to restore to the 30th of May backup but it fails when prompted for the passphrase.

I have the correct passphrase, but cannot get it into the process.

I did try the LUKS passphrase I created along with the other distro thumbdrive during the EVENT - it doesn't work either.

Since it happened I used the machine several times to get a copy of Clonezilla that worked and to then make two image copies of the sda3. I also used install thumbdrives of Neon and 18.04 Ubuntu (Server & Desktop) to try to reinstall Grub w/o success (had no clue how to access the install OSes' features to re-install Grub) and used Neon again to get the details of the LUKS & sda3 partition.

I stopped using Deja Dup & Duplicity to make incremental backups of the critical folders of mine a few months ago because that never worked, they kept creating massive files totaling very many times more data than the size of my whole OS' SSD. So I continually ran out of space and therefore had no confidence in whatever was being saved. I had specifically chosen to have incremental backups, which the apps claimed would overwrite earlier versions, but both just stopped once their large partition was full and simply put up notifications that it was full - never deleted any of the huge number of files they had produced.

I had been making space on an external drive to copy over all my personal data, screen recording of all installed apps and ppa lists; and probably this week do a clean install of the latest KDE Neon, having tried and deleted various apps, and wanted to thin it out of pointless files. Like everyone who has just lost access to their files, I am also saying that it is months of valuable work that I do not want to try to replace - I just didn't find a backup app that appealed to me or actually worked and just kept putting off trying another one.

I install Timeshift whenever I do a clean install because it has always worked as claimed. So I do have a 30may2020 backup of the system files, along with a few prior dates - but no personal files, that's not what Timeshift is used for.

- - -

https://gitlab.com/cryptsetup/crypts...-data-recovery

I have read the Backup and Data Recovery section, some of which reads like I can possibly create a new header and it may be alright, but some parts sound like it will make it absolutely unrecoverable.

My goal in opening the LUKS volume is to immediately copy the personal data files from it and then urandom wipe it and install a new LUKS encrypted KDE Neon AND THEN BACK UP THE LUKS FILES suggested on the gitlab-cryptsetup website and purchase another drive to try some other backup software and give it huge space to duplicate files. So if you have a suggestion that won't make the volume function as it used to but will allow me to access the files in the finder of an USB install drive - that is all I need.

Does the fact that I have Timeshift backups offer any help in getting a header or whatever out of them to open the SSD which is currently inaccessible; i.e. original undamaged LUKS headers? Or is it a matter that the encrypted SSD cannot be accessed deep enough to replace the one that I assume to be damaged?

Or is this more likely to be some issue other than the LUKS header being damaged?

Thank you for your help.

- - -

Miscellaneus terminal entries/results are listed below:

I have done this: sudo cryptsetup luksDump /dev/sda3
And I assume that "Version: 1" means this is a LUKS1 installation. Is that true?

The luksDump returns this:
Crypto backend (gcrypt 1.8.1) initialized in cryptsetup library version 2.0.2.

sudo cryptsetup luksOpen /dev/sda3/ sda3_crypt
Results in: Device /dev/sda3/ doesn't exist or access denied.
Despite the fact that "sudo blkid | grep crypto" lists sda3 as the LUKS volume.

----------
neon@neon:~$ dmsetup ls
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.145 (2017-11-03) and kernel driver (unknown version).
Command failed


Name: sda3_crypt
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
Open count: 2
Event number: 0
Major, minor: 253, 0
Number of targets: 1
UUID: CRYPT-LUKS1-df736320c6fa49c8af427b3658b73a73-sda3_crypt

neon@neon:~$
----------
neon@neon:~$ sudo dmsetup status /dev/dm-0
0 466307072 crypt
---------
neon@neon:~$ sudo cryptsetup open /dev/sda3 sda3_crypt -- type luks
Enter passphrase for /dev/sda3: Error reading passphrase from terminal.
neon@neon:~$ blkid -t TYPE=crypto_LUKS -o device
/dev/sda3
neon@neon:~$ dmsetup table /dev/mapper/sda3_crypt --showkeys
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.145 (2017-11-03) and kernel driver (unknown version).
Command failed
neon@neon:~$ sudo cryptsetup -v isLuks /dev/sda3
Command successful.
neon@neon:~$ sudo dmsetup table --target crypt --showkey /dev/mapper/sda3
Device /dev/mapper/sda3 not found
Command failed
neon@neon:~$ sudo dmsetup table --target crypt --showkey /dev/mapper/sda3_crypt
0 466307072 crypt aes-xts-plain64 e01b2791aa73d65c1b5b0d5d47afa3edabcd54252be070a4eecf88ae2ce968ab505d5f8d19177589c9a4514b2547c2e78c4a 01e52ed5b74d957fbbe5487bb86d 0 8:3 4096
neon@neon:~$
----------
neon@neon:~$ sudo cryptsetup luksDump /dev/sda3 --debug | grep backend
# Initialising device-mapper backend library.
# Crypto backend (gcrypt 1.8.1) initialized in cryptsetup library version 2.0.2.
# Releasing device-mapper backend.
neon@neon:~$
----------
neon@neon:~$ sudo cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
MK digest: 8e d7 1b 4a a0 de ee 10 18 e4 42 31 9c dd 7d 34 15 c9 52 55
MK salt: b4 4c df 25 ca 08 82 13 c0 c8 94 0a a1 fc ac 17
0a be 4e b4 a3 f0 f2 97 77 da 0f 34 a6 ab 82 c9
MK iterations: 108145
UUID: df736320-c6fa-49c8-af42-7b3658b73a73

Key Slot 0: ENABLED
Iterations: 1730322
Salt: 9a e3 7f 43 9c 43 cc 3f bc 80 41 b9 38 b4 63 85
ac dd 7f 5c 2b cf 2a 79 15 d6 5f 8f 89 59 e7 55
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
neon@neon:~$ sudo cryptsetup luksDump /dev/sda3

For somebody willing to help you, it's hard to cut through all the irrelevant history with Clonezilla and Timeshift and the failed commands. My conclusion is that you have no backup of your data, /dev/sda3 is the encrypted root disk, your PC doesn't boot from it and you have been unable to mount /dev/sda3 on a rescue system. Is that correct?

For the future, formatting disks on a system that contains valuable data without backup is not a great idea. In fact, valuable data without a backup is not a great idea to begin with.

Before you do anything that modifies /dev/sda3, make a copy of it. I understand that you have that plan.

It looks like cryptsetup sees a valid LUKS header. This indicates that the beginning of sda3 was not overwritten, but just in case, you may want to check if there is a LUKS header backup somewhere. The partition table on sda wasn't overwritten either, since you still have sda3. These are good news.

It's not clear to me if you tried opening the LUKS device. At one point, luksOpen reports that the device doesn't exist, although luksDump succeeds. At another point, you run cryptsetup open with a blank between the double dash and the word "type". In spite of this incorrect input, this seems to succeed except for the passphrase. Did you enter a passphrase at that moment?

I'd like to see another attempt at opening the LUKS device, right after a luksDump, and possible error codes. Such as
Oh, and please format your input and output as code for better readability.

That is correct.

The day after I made 2 copies via Clonezilla onto a larger hard drive.

I did.

Here are the results of your request:
I did enter the passphrase when requested.

Thank you for your help.

If you will indicate exactly which file(s) to look for I can search my 30may Timeshift backup for it.

It looks like it's already open. What do the commands blkid and lsblk tell you?

They are not created automatically. You would have created them, and they can have any name.

Please read the post, I edited the beginning. Thank you.

It archives a complete install with normal paths, etc. I meant that if you ask me to search for headers.luks or some specific system files or folders I can easily do that. etc/ bin/ whatever/ ...

0 means that the command succeeds.
It means that the mount point exists, probably because you created it earlier. Just mount the filesystem.

I believe that you run these commands from the live system (USB drive). What you can do now is save all the files, or the ones that include your work. After that, you can investigate what prevents this disk from booting, or simply reinstall your operating system.

I just saw this line. This is not a filesystem, i.e. you can't mount it. It's an LVM physical volume that probably contains logical volumes that you can mount. You see the logical volume in the lsblk output, but not blkid. Try to mount it anyway:
However I have the fear that your accidentally installing something on that disk generated this logical volume, thereby overwriting whatever was on it before.

That didn't work.

Just in a few seconds? Or are you referring to some LVM data?

Well, you have to create the mountpoint first.

From your tale, I understand that you accidentally started disk initialization with /dev/sda. My fear is that this encrypted partition sda3 and created an LVM structure on top of the encrypted disk. This takes a fraction of a second, I am afraid. If that's what happened, you lost your original LUKS header. Without that header, there is no chance (exactly 0%) that you can recover any data. If you had a backup of that header, there might still be some data on the disk that can be recovered with forensic tools.

But perhaps I am wrong. First try to create the mountpoint and mount the volume again.

Are you saying that these UUIDs may have NOTHING to do with my original LUKS volume? That they were newly generated during those few seconds when I made the mistake?

If you can tell me exactly what LUKS or crypt files to look for in my Timeshift system file backups I can find them. Is there a file there that would have UUIDs from my original LUKS volume, so that they could be compared with the above and the one in the GParted attachment photo? We would at least know if they are the same or indeed have been changed.

Thanks again.

There are 1,290 files with the word "crypt" in it and 10 files with the work "luks" in it. This in my 30may2020 Timeshift backup.