Bug 218840 - gnome-mount does not automount hotplugged luks volumes
Summary: gnome-mount does not automount hotplugged luks volumes
Status: CLOSED DUPLICATE of bug 209590
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-mount (Show other bugs)
(Show other bugs)
Version: 6
Hardware: All Linux
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-12-07 19:48 UTC by Piergiorgio Sartor
Modified: 2013-03-06 03:48 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-30 18:41:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output of gnome-mount -v -b -t -d ... (718 bytes, text/plain)
2007-01-15 18:49 UTC, Michael Jakob
no flags Details

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):

How reproducible:

Steps to Reproduce:
Hotplug an external storage device with luks partition
Provide proper password when requested
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-  I tried to
run gnome-mount manually (after removing the luks device again with cryptsetup)
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
Enter password to unlock encrypted data for /dev/sda1: 
** (gnome-mount:15696): DEBUG: Setting up
for crypto

** (gnome-mount:15696): WARNING **: Setup failed for
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


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 ***

Note You need to log in before you can comment on or make changes to this bug.