Can't mount a LUKS volume after unmounting

[tiago]

Binary package hint: gnome-volume-manager

I have a USB disk with a LUKS ext3 encrypted partition. When I plug it in for the first time, gnome detects the encrypted partition, asks me for the password, and mounts the device. If I unmount it and them plug it in again, it fails to mount the volume again. In nautilus "computer:/// ", the volume name is still there. When I double click it to access it it says:

"Unable to mount the volume xpto"

Details:

"mount: special device /dev/mapper/luks_crypto_(...) does not exist"

However, if I use cryptsetup and mount manually, I can mount the volume.

I'm using Gutsy, as updated on 19/10/2007. This problem did not occur with Feisty. Maybe this is a udev or kernel related issue. I noticed in Feisty that if I unmounted a USB device and mounted it again, the device name would be different. Eg., if this device was /dev/sdb when mounted for the first time, the second time it got mounted it would be /dev/sdc, the third time /dev/sdd, etc. With Gutsy, if I mount the device again it's name is again /dev/sdb. Maybe the gnome volume manager associates this device name to the particular LUKS device map created the first time, and tries to mount it again, without calling cryptsetup. Then it fails, because the mapper device does not exist anymore and cryptsetup needs to be called to create a new one.

[tiago (tiagomdp)]

I should just add that if the device name for this device is changed (for instance, if I mount another USB device first), then when I try to mount it a second time, gnome will ask for the password and mount it correctly.

[Robert W. Brewer (rwb123)]

I confirm that I am seeing a similar if not identical problem. I have an external USB drive formatted with Luks and ext3. I'm running gutsy on amd64 and have the update manager enabled.

[Nikolaus Rath (nikratio)]

Same problem here since the upgrade to gutsy. Luks volumes can only be mounted the first time the device is connected, subsequent attempts fail with "special device /dev/mapper/luks_crypto_(...) does not exist".

After manually creating the device mapper device, e.g. with

# cryptsetup luksOpen /dev/sdb3 secure

the /dev/mapper/secure volume is automatically mounted correctly.

I think the problem is also not related to the volume having the same device name for every connect in gutsy. For me feisty behaved the same way: my external harddrive was always accessible as /dev/sdb, no matter how often I reconnected it.

[Nikolaus Rath (nikratio)]

Attaching debugging files described in https://wiki.ubuntu.com/DebuggingRemovableDevices

[Nikolaus Rath (nikratio)]

[0] nokile:~$ id
uid=1000(nikratio) gid=1000(nikratio) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(lpadmin),105(scanner),106(admin),1000(nikratio)
[0] nokile:~$ id hal
id: hal: No such user
[1] nokile:~$ id haldaemon
uid=116(haldaemon) gid=116(haldaemon) groups=116(haldaemon),24(cdrom),25(floppy),46(plugdev),126(powerdev)
[0] nokile:~$ uname -a
Linux nokile 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
[0] nokile:~$

[Nikolaus Rath (nikratio)]

The above logs have been created while plugging in a usb harddrive with two unencrypted partitions, sdb1 and sdb3 that are mounted correctly, and an encrypted partition sdb2 that is not mounted.

[Nikolaus Rath (nikratio)]

I also observed the following here:

When the device is plugged in, gnome-keyring asks me for the passphrase. If I give the passphrase, the described bug occurs. However, if I deny the question then gnome-mount itself also asks me for the passphrase. If I then give the passphrase in this second dialog, mounting works correctly.

Can someone else confirm this behaviour as well?

[John Ross (johnross-johnross)]

I've seen this bug as well. It occurs with firewire and usb drives. It appears to assign a new device name each time the drive is plugged in. I wonder how many times this would have to happen before something bigger breaks? This bug is very frustrating since I'm using fully encrypted disks throughout my operation and use . What's the odds of getting a fix on this one sometime soon?

[John Ross (johnross-johnross)]

BTW: A reboot causes the system to prompt for password again.

[Peter Wainwright (prw)]

Looks like it maybe related to Bug #148003.

IMHO, it's a race between udev and cryptsetup (libdevmapper).

I "fixed" it by removing /etc/udev/rules.d/65-dmsetup.rules.

This file seems to have been introduced by a recent Ubuntu patch. Presumably there was a good reason for it, but it causes havoc.

[Fabián Rodríguez (magicfab)]

This is in fact a duplicate of Bug #148003. See that bug for a workaround.