11

I'm having problems unlocking a luks-encrypted disk with KDE dolphin, in a system with manjaro.

The issue is not critical. It can be solved by rebooting, but sometimes it is not convenient to do so, and I find that it might be useful to understand why this problem appears in the first place.

So the first time I unlock the device after a reboot everything is fine. If I unmount the system, next times will also be ok. The problem is that sometimes, I connect the device, and after entering the password I get the following error:

An error occurred while accessing 'Home', the system responded: The requested operation has failed: Error unlocking /dev/sdxy: Failed to activate device: File exists

But this file cannot be seen with df -h, and it is not mounted via /etc/fstab, it is always mounted and unlocked when connected. The command fuser won't show anything relevant, and lsof only returns:

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse file system /run/user/1000/doc
      Output information may be incomplete.

In fact, I see some processes using this folder (ps aux | grep 1000), but do not know whether this actually helps to solve the problem.

1779 ?        Sl     0:03 /usr/lib/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
1847 ?        S      0:03 file.so [kdeinit5] file local:/run/user/1000/klaunchermRxLKs.1.slave-socket local:/run/user/1000/kded5IKggHu.1.slave-socket
23434 ?        S      0:00 file.so [kdeinit5] file local:/run/user/1000/klauncherDwiyfV.1.slave-socket local:/run/user/1000/dolphinaVwzoi.58.slave-socket

I suspect killing these processes might help, but do not know if it's safe (cannot risk to do so right know, not without knowing). Any ideas?

EDIT: Output for dmsetup info and dmsetup table:

dmsetup info

Name:              luks-92bde790-5ca6-441b-bad3-5c3163292c8b
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      254, 1
Number of targets: 1
UUID: CRYPT-LUKS1-92bde7905ca6441bbad35c3163292c8b-luks-92bde790-5ca6-441b-bad3-5c3163292c8b

Name:              luks-1f919383-2d4a-44e2-b28e-21bffd11dd6c
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      254, 0
Number of targets: 1
UUID: CRYPT-LUKS1-1f9193832d4a44e2b28e21bffd11dd6c-luks-1f919383-2d4a-44e2-b28e-21bffd11dd6c

dmsetup table

luks-92bde790-5ca6-441b-bad3-5c3163292c8b: 0 4294963200 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:33 4096
luks-1f919383-2d4a-44e2-b28e-21bffd11dd6c: 0 3906401473 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:2 4096
elcortegano
  • 233
  • 1
  • 3
  • 8
  • 1
    random shoot: maybe `dmsetup info` or `dmsetup table` would show a stale entry for this disk in case it was forcefully removed before? – A.B Oct 11 '19 at 19:51
  • It is indeed possible that the disk was forcefully removed. I have updated the post with that information. – elcortegano Oct 16 '19 at 13:50
  • To verify what I was saying, would require running `sync` and after it forcefully removing the device (here is it the one with /dev/sdb2, /dev/sdc1 or both? I'm not responsible of potential data loss of course) and then to check if the relevant entry still exists with dmsetup – A.B Oct 16 '19 at 18:54
  • Solution for the similar case where this error message appears already at the first attempt, and you're dealing with cloned disks: https://askubuntu.com/a/1278396 – tanius Sep 28 '20 at 16:42

3 Answers3

14

If, after looking at the output of dmsetup ls you find that you have stale devices you can remove them with dmsetup remove – ideally after carefully verifying that the device is indeed not in use.

I had the same problem and after doing so I was able to unlock and mount my encrypted USB hard disk again:

# dmsetup ls --tree
luks-f53274db-3ede-4a27-9aa6-2525d9305f94 (254:5)
 `- (8:34)

# ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 Nov 24 15:22 control
lrwxrwxrwx 1 root root       7 Nov 27 09:42 luks-f53274db-3ede-4a27-9aa6-2525d9305f94 -> ../dm-5

# dmsetup remove /dev/dm-5
MartinR
  • 176
  • 1
  • 4
  • 3
    I was also having `Device or resource busy` errors. Used `sudo lsof | grep 254,5` (following numbers in the example above), and killed processed linked to the device. After that, your solution worked. Thanks! – elcortegano Jun 18 '21 at 15:41
  • @elcortegano, no luck for me finding what is using it in this way :/ – akostadinov Oct 12 '21 at 22:48
5

I encountered the same error (also using KDE on Manjaro). I have a LUKS volume on a USB device which wasn't cleanly removed from the computer. When I reinserted the USB device, the LUKS volume refused to unlock:

# udisksctl unlock -b /dev/sdg1
Passphrase:
Error unlocking /dev/sdg1: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/sdg1: Failed to activate device: File exists

Since I was trying to unlock the device /dev/sdg1, I didn't understand how @MartinR had identified the offending volume UUID (instead of, say, some other LUKS volume which didn't have trouble) in their answer particularly since the entry in /etc/fstab has a different UUID than what's listed in /dev/mapper.

# grep /mount/point /etc/fstab
UUID=33333333-3333-3333-3333-333333333333 /mount/point ext4 defaults 0 0
# ls -lah /dev/mapper
total 0
crw------- 1 root root 10, 236 Oct 10 06:08 control
lrwxrwxrwx 1 root root       7 Oct 10 06:08 luks-11111111-1111-1111-1111-111111111111 -> ../dm-1
lrwxrwxrwx 1 root root       7 Oct 10 17:41 luks-22222222-2222-2222-2222-222222222222 -> ../dm-2
lrwxrwxrwx 1 root root       7 Oct 10 06:08 luks-00000000-0000-0000-0000-000000000000 -> ../dm-0

I was able to verify which LUKS volume UUID was having trouble using udisksctl with the device partition.

# udisksctl info -b /dev/sdg1 | grep 'IdUUID'
IdUUID:                     22222222-2222-2222-2222-222222222222

At that point, it was clear which dm object needed to be cleaned.

# dmsetup ls
luks-00000000-0000-0000-0000-000000000000       (254:0)
luks-11111111-1111-1111-1111-111111111111       (254:1)
luks-22222222-2222-2222-2222-222222222222       (254:2)
# dmsetup remove /dev/dm-2

Then, unlocking and mounting succeeded.

# udisksctl unlock -b /dev/sdg1
Passphrase:
Unlocked /dev/sdg1 as /dev/dm-2.
# mount /mount/point
inetknght
  • 150
  • 1
  • 4
0

In my case there was a problem in /etc/crypttab.

I followed some tutorial without really understanding it so I created a file like:

secret UUID=AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA /root/AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA.lukskey
secret UUID=BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB /root/BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB.lukskey

and was getting the error, because as a consequence of the config above, the system was trying to create /dev/mapper/secret for each of the lines and the second failed.

It got ok after changing it into:

luks-AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA UUID=AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA /root/AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA.lukskey
luks-BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB UUID=BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB /root/BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB.lukskey

That lead to the creation of /dev/mapper/luks-AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA and /dev/mapper/luks-BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB.

user1182474
  • 371
  • 3
  • 5