Description of problem: Well, maybe I'm missing something, but the gnome-mount behaviour, with luks, does not really seems to work to me. I've some external HDDs with luks volume, the automount is enabled within gnome-volume-manager and it is working with other "normal" external HDDs. When hoplugging the device, gnome-mount asks for the password and then the /dev/mapper/luks_XYZ entry is created, but no partition is actually mounted. Under nautilus, the volume is shown (with no name), but, again, double clicking on it results in another password request, with no actual different results. Of course the luks volume is ext3 formatted, i.e. it has a valid ext3 partition and, in fact, it is mountable from shell (by root). Maybe this is the wanted behaviour, i.e. maybe the user is forced to mount the luks partition by hand, even if it does not seems consistent to me. Another possibility is that my system is someone misconfigured. Either way, I submit this bug report, in the hope to get some fix and/or answer. Version-Release number of selected component (if applicable): 0.5-2.fc6 How reproducible: Always Steps to Reproduce: 1. Hotplug an external storage device with luks partition 2. Provide proper password when requested 3. Actual results: The luks device is mapped as /dev/mapper/luks_XYZ, but is then not mounted. Expected results: The luks partition should appear under /media Additional info: I tried with a device where the luks volume was build on /dev/sdb (i.e. the whole device) or on /dev/sdb1 (first an unique partition), with same results.
Created attachment 145605 [details] output of gnome-mount -v -b -t -d ... I can confirm this bug (gnome-mount-0.5-2.fc6, hal-0.5.8.1-6.fc6). I tried to run gnome-mount manually (after removing the luks device again with cryptsetup) and produced the attached log.
I am experiencing a new problem with gnome-mount and an external USB HD that is encrypted with LUKS. This just began yesterday, after some updates, which included (notably udev): Jan 15 17:27:27 Updated: avahi.i386 0.6.16-1.fc6 Jan 15 17:27:29 Updated: libselinux.i386 1.33.3-2.fc6 Jan 15 17:27:30 Updated: avahi-glib.i386 0.6.16-1.fc6 Jan 15 17:27:47 Updated: evolution-data-server.i386 1.8.2-2.fc6 Jan 15 17:27:57 Updated: shadow-utils.i386 2:4.0.17-12.fc6 Jan 15 17:27:58 Updated: avahi-qt3.i386 0.6.16-1.fc6 Jan 15 17:27:59 Updated: libvolume_id.i386 095-17.fc6 Jan 15 17:28:43 Updated: gnucash.i386 2.0.4-1.fc6 Jan 15 17:28:47 Updated: gettext.i386 0.14.6-4.fc6 Jan 15 17:28:56 Updated: sysklogd.i386 1.4.1-41.fc6 Jan 15 17:29:03 Updated: squid.i386 7:2.6.STABLE7-1.fc6 Jan 15 17:29:06 Updated: evolution-data-server-devel.i386 1.8.2-2.fc6 Jan 15 17:29:09 Updated: gawk.i386 3.1.5-14.fc6 Jan 15 17:29:10 Updated: avahi-devel.i386 0.6.16-1.fc6 Jan 15 17:29:12 Updated: avahi-tools.i386 0.6.16-1.fc6 Jan 15 17:29:13 Updated: w3m.i386 0.5.1-15.fc6 Jan 15 17:29:14 Updated: libselinux-python.i386 1.33.3-2.fc6 Jan 15 17:29:16 Updated: libselinux-devel.i386 1.33.3-2.fc6 Jan 15 17:29:17 Updated: python-numeric.i386 24.2-1.fc6 Jan 15 17:29:19 Updated: udev.i386 095-17.fc6 Jan 15 22:48:11 Updated: yum-metadata-parser.i386 1.0.3-1.fc6 Jan 15 22:48:14 Updated: yum.noarch 3.0.3-1.fc6 Jan 15 22:48:16 Updated: yum-updatesd.noarch 3.0.3-1.fc6 My /dev/mapper includes the USB HD: $ ls /dev/mapper control home luks_crypto_20e331c9-2bb3-4f5f-966f-f27d5cb45e76 swap tmp var I can manually open and mount the USB HD using: $ sudo /sbin/cryptsetup luksOpen /dev/sda1 sda1 Enter LUKS passphrase: key slot 0 unlocked. Command successful. $ sudo mount /dev/mapper/sda1 /media/disk after manually making the 'disk' mount point. It should be noted that the gnome-mount GUI does come up when plugging in the drive. It accepts the correct passphrase, but nothing happens. If I enter the incorrect passphrase, it does re-prompt me. From the CLI I get: $ gnome-mount -v -b -t -d /dev/sda1 gnome-mount 0.5 libhal-storage.c 1401 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was not set. ** (gnome-mount:15696): DEBUG: Crypto volume - UDI '/org/freedesktop/Hal/devices/volume_uuid_20e331c9_2bb3_4f5f_966f_f27d5cb45e76' Enter password to unlock encrypted data for /dev/sda1: ** (gnome-mount:15696): DEBUG: Setting up /org/freedesktop/Hal/devices/volume_uuid_20e331c9_2bb3_4f5f_966f_f27d5cb45e76 for crypto ** (gnome-mount:15696): WARNING **: Setup failed for /org/freedesktop/Hal/devices/volume_uuid_20e331c9_2bb3_4f5f_966f_f27d5cb45e76: org.freedesktop.Hal.Device.Volume.Crypto.SetupError : /dev/sda1 is already setup? Up until yesterday, this all worked fine, with the GUI prompting me for the passphrase and then mounting the drive. As noted above, the drive does appear in Nautilus, though with the correct name "232.9 GB Volume". Setting SELinux to Permissive had no effect, so I don't think that this is a policy issue. Let me know if you need additional info.
I forgot that this issue is related to a udev rules change. Folks might want to look at Bug #209590, where I uploaded a new patch file today, to update an older version that had been posted by another user. With this change to /etc/udev/rules.d/50-udev.rules, I am back to running fine again. Thanks.
Confirmed; your patch solves the issue for me. Hm, I find it really hard to figure out how all that automounter stuff interacts. My understanding was that hal/gnome-mount etc. was meant to replace udev, at least under gnome. I think I should RTFM, if only I could find some recent documentation... However, thanks.
*** This bug has been marked as a duplicate of 209590 ***