Bug 218840

Summary: gnome-mount does not automount hotplugged luks volumes
Product: [Fedora] Fedora Reporter: Piergiorgio Sartor <piergiorgio.sartor>
Component: gnome-mountAssignee: David Zeuthen <davidz>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: marc_schwartz, mclasen, mjakob
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-30 18:41:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output of gnome-mount -v -b -t -d ... none

Description Piergiorgio Sartor 2006-12-07 19:48:03 UTC 
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.
Comment 1 Michael Jakob 2007-01-15 18:49:43 UTC 
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.
Comment 2 Marc Schwartz 2007-01-16 14:00:02 UTC 
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.
Comment 3 Marc Schwartz 2007-01-17 04:28:34 UTC 
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.
Comment 4 Michael Jakob 2007-01-17 18:54:35 UTC 
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.
Comment 5 David Zeuthen 2007-01-30 18:41:11 UTC 

*** This bug has been marked as a duplicate of 209590 ***