# Serious LUKS/cryptsetup problem. HELP!!![SOLVED]

## Budoka

I want to punch a wall. OK. Now that I have that out of my system.

Please excuse the length of this post but I rather provide everything I did so that you guys and gals can give me the best feedback possible.

I have a 1TB external drive that I have been backing up to "semi" regularly. (Yeah I know. LOL) I had encrypted it with LUKS when initially setting up and hadn't encountered any problems until recently. 

So I find I need to use this drive because my internal disk is failing. So yesterday I plug it into the USB port and when I am prompted for the password, enter it and..."you are not authorized to mount/unlock this device". The password wasn't incorrect and I tried for hours to figure out what the h*ll could be going on. Caps lock on, entering it incorrectly, etc So now I am freaking out because the back up I do have is encrypted and my key/password isn't unlocking the disk. So I decide to leave it alone for a day and really think if maybe I had used another password. This morning I connect the disk to my box...and when prompted for the password...enter the one I am pretty sure it was (the same one I tried for hours to use the previous day) and BAM I am in! User error the previous day...maybe. 

So I was concerned that if I disconnect the disk and I run into the same problem I am screwed so decide to temporarily remove the password. I used

```
 cryptsetup luksRemoveKey /run/media/t***/1TB\ External/

```

(I edited part of the path because it contains identifiable information.) I don't get any feedback and it brings me back to the command line. Hmmm. Does this mean the password has been removed now? So in an over abundance of caution, I decided to add a new password. So I execute

```
cryptsetup luksAddKey /run/media/t**/1TB\ External/ 

```

I get no feedback or prompts and I am returned to the command line. Hmmm. OK let me verify the password I do have...

```
cryptsetup -y /run/media/tl**/1TB\ External/

```

returns

 *Quote:*   

> cryptsetup: Unknown action.
> 
> 

 

Then upon doing some further research, it appears that I should have been using the /dev path with these commands.  So I verify that the drive is at sdc1 and  I execute 

```
cryptsetup luksDump /dev/sdc1
```

 It returns  *Quote:*   

> LUKS header information for /dev/sdc1
> 
> Version: 1
> 
> Cipher name: serpent
> ...

 

OK. Looking good. So I add a password to make sure I can get back in...

```
# cryptsetup luksAddKey /dev/sdc1

Enter any existing passphrase:

Enter new passphrase for key slot:

Verify passphrase:
```

Looks good. Entered twice and verified. Double check...

 *Quote:*   

> cryptsetup luksDump /dev/sdc1
> 
> LUKS header information for /dev/sdc1
> 
> Version: 1
> ...

 

OK, So slot 1 and 2 both have a password and are enabled. I didn't want to remove the first one to be "safe".

So I disconnect the drive...reconnect it...am prompted for the unlock password and  YOU ARE NOT AUTHORIZED...blah blah. WTF. The password is NOT INCORRECT. So I can't open this disk again and neither password assigned is incorrect. No caps locks etc.

Strange thing is that at the CLI I can still execute...cryptsetup luksDump /dev/sdc1 get a return. I can also add another password. It prompts me for my current password which it ACCEPTS then prompts to enter new password. I didn't do so yet because I don't want to complicate this further. 

OK. I haven't any doubt that there is something going on here that has more to do with me than crypsetup but not sure what it is. 

I have got to get back into this drive.

The password I am entering is not incorrect or being mistyped.

WTF? Any ideas?

What am I doing wrong? Google-fu isn't helping.Last edited by Budoka on Tue Sep 05, 2017 2:06 pm; edited 1 time in total

----------

## R0b0t1

The error message about authorization seems like it isn't from cryptsetup. What is printed if you mistype the password when adding or removing a key?

----------

## The_Great_Sephiroth

I am not sure what DE you're running (KDE, Gnome, etc) but it may be a GUI bug. Plasma is currently bugged for basic things like removable media. The notification in the system tray says I can click to open it in Dolphin, but then it tells me I do not have permission. If I go to Dolphin and click the drive it mounts and I can access it just fine. I CAN use the system tray notification to safely remove the drive, however. Perhaps this is a similar issue? Tried mounting it via shell only?

----------

## Budoka

 *The_Great_Sephiroth wrote:*   

> I am not sure what DE you're running (KDE, Gnome, etc) but it may be a GUI bug. Plasma is currently bugged for basic things like removable media. The notification in the system tray says I can click to open it in Dolphin, but then it tells me I do not have permission. If I go to Dolphin and click the drive it mounts and I can access it just fine. I CAN use the system tray notification to safely remove the drive, however. Perhaps this is a similar issue? Tried mounting it via shell only?

 

Wow. Thank you and everyone else who commented. This is exactly what it was. The "bug" is in both KDE and XFCE. Should I report this and if so where?

I nearly had a heart attack. LOL

----------

## The_Great_Sephiroth

I have no idea where, but this was not an issue until Plasma was released. To this day the notification icon will not allow users to mount USB attached storage on any Gentoo systems, but Dolphin does it just fine. Glad I could help and I'm glad your data is good.

----------

## Hu

As a bit of general advice, when you encounter a problem like this, bypass any intermediate layers.  Use straight command-line tools to examine / modify the state.

Personally, I would consider your experience with cryptsetup verb path to indicate a user interface bug.  Cryptsetup should have given you a sensible error message (telling you to use a file/device, not a directory) for each of those commands, not only for when you tried with -y.  (It does exit with a nonzero error code in that case, but as you observed, no message, so if you do not think to check $?, there will be no indication what happened.)  In particular, it looks to me like you got lucky here.  It tried to interpret your path as a verb, and that was what provoked Unknown action, which in turn prompted you to reread the documentation and discover your usage error.

----------

## Budoka

 *Hu wrote:*   

> As a bit of general advice, when you encounter a problem like this, bypass any intermediate layers.  Use straight command-line tools to examine / modify the state.
> 
> Personally, I would consider your experience with cryptsetup verb path to indicate a user interface bug.  Cryptsetup should have given you a sensible error message (telling you to use a file/device, not a directory) for each of those commands, not only for when you tried with -y.  (It does exit with a nonzero error code in that case, but as you observed, no message, so if you do not think to check $?, there will be no indication what happened.)  In particular, it looks to me like you got lucky here.  It tried to interpret your path as a verb, and that was what provoked Unknown action, which in turn prompted you to reread the documentation and discover your usage error.

 

Agreed and lesson learned. I really almost had a heart attack. Haha.

Anyway, thanks everyone.

----------

