inconsistent automounting on startup

Bug #396448 reported by Martin Pitt on 2009-07-07
244
This bug affects 46 people
Affects Status Importance Assigned to Milestone
gvfs
Fix Released
Medium
obsolete
Fix Released
Medium
devicekit-disks (Ubuntu)
High
Martin Pitt
Karmic
High
Martin Pitt
gvfs (Ubuntu)
High
Martin Pitt
Karmic
High
Martin Pitt

Bug Description

Binary package hint: devicekit-disks

When starting a GNOME session without dk-disks running already, gvfs D-BUS activates dk-disks, which causes an automount attempt on internal hard disks. This doesn't happen if dk-disks is already running.

I suspect it's due to dk-disks sending out "new volume" events during coldplugging.

Reproducer:

  ps ux|grep gvfs|awk '{print $2}'|xargs kill
  gvfs-mount -l

This does not trigger automounting. However, if this spawns dk-disks it happens:

  sudo killall devkit-disks-daemon
  ps ux|grep gvfs|awk '{print $2}'|xargs kill
  gvfs-mount -l

Created an attachment (id=27449)
debug output

This is the devkit-disks-daemon output when being d-bus activated through gvfs. The log shows that initially the internal hard disk partitions (sdaX) are added:

**** ADDING /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda3
**** UPDATING /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda3

This shouldn't emit events (device_add() gets called with emit_event==FALSE from devkit_disks_daemon_new()), but right after that I get change events as well:

**** CHANGING /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda3
**** UPDATING /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda3

"udevadm monitor --udev -e" doesn't show anything coming from udev

(In reply to comment #1)
> Created an attachment (id=27449) [details]
> debug output
>
> This is the devkit-disks-daemon output when being d-bus activated through gvfs.
> The log shows that initially the internal hard disk partitions (sdaX) are
> added:
>
> **** ADDING
> /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda3
> **** UPDATING
> /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda3
>
> This shouldn't emit events (device_add() gets called with emit_event==FALSE
> from devkit_disks_daemon_new()), but right after that I get change events as
> well:
>
> **** CHANGING
> /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda3
> **** UPDATING
> /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda3
>

I don't get any add events from devkit-disks-daemon using 'devkit-disks --monitor', only some 'change' event which is correct since we read ATA SMART data async on startup. It would be a bug to get 'add' events on coldplug, sure.

Please verify it's the same for you (and state the version - if see the bug, please also try with HEAD).

FWIW, it's true, that the debug spew from the daemon is misleading - that's just because daemon startup involves coldplug and the same codepaths are reused.

Download full text (4.7 KiB)

Hi,

This is not really a DeviceKit-disks bug, it's a gvfs bug. Anyway, let me try and explain how this is supposed to work since this information applies to any environment attempting to enforce policy. When I've done that, I'll address your bug report and then I'll move the bug to the GNOME bugzilla.

First of all, automounting (and, for that matter, also: autoassemby of RAID arrays, auto unlocking LUKS devices, autoassembly of LVM logical volumes, establishing connections to preconfigured iSCSI connections) is a really tricky business (we don't yet handle LVM or iSCSI but that is on the road map).

This is especially true if you want the added geek-comfort of things working perfectly with the classic command line tools such as fdisk(8), parted(8), mkfs(8), mdadm(8) and so on. And, in GNOME at least, we do want that level of geek-comfort.

For example, if you use the low-level tools from gnome-terminal within a GNOME desktop session, we want the following user experience

 1. The desktop shell (e.g. file manager, Places menu in panel, Disk
    Mounter applet, file chooser dialogs) should always reflect the current
    state of affairs - for example, if you add/remove partitions with fdisk(8)
    or parted(8) then you want the desktop shell bits to be instantly updated.
    Ditto if you create file systems. Ditto if you create a new RAID device.
    and so on.

The way we implement (most of) 1. is through having udev listen on changes on block devices with inotify. E.g. every time the last opener of a O_RDRW file descriptor for a block device closes his fd, then udev will synthesize a 'change' uevent.

Now, this 'change' event bubbles through the udev stack, triggers file system probing (60-persistent-storage-rules.udev), and then gets delivered to devkit-disks-daemon which acts on it (typically turning it into one or more D-Bus signals).

Eventually, the event from devkit-disks daemon reaches the GIO volume monitor implemetation (gvfs-gdu-volume-monitor) in your desktop session and it is turned into appropriate signals on GVolumeMonitor and GDrive/GVolume/GMount objects.

Finally, the desktop automounter (and, in the future, autoassembler) that (currently) resides in the Nautilus process acts on these events.

 2. We _only_ want the desktop automounter (and, in the future,
    autoassembler) to take action if a couple of conditions are true,
    typically if it looks like you've just inserted the device (for example
    a USB enclosure with non-removable media) or just inserted the media
    for which the block device in question in residing on (for example if
    you just inserted a CF card into a USB card reader).

    For example, if you create a new partition with fdisk(8) things might
    just happen to be in a state (depending on the phase of the moon) so
    the newly created partition is picked up (by fs probers invoked by udev)
    as a mountable file system. This is typically due to fdisk(8) not clearing
    filesystem signatures on the partition. FWIW, This happens more
    frequently than you'd expect since many users use same/similar sizes
    when repartioning media.

    (Of course, if you create partitions/filesystems via t...

Read more...

Download full text (3.7 KiB)

(In reply to comment #0)
> When starting a GNOME session without dk-disks running already, gvfs D-BUS
> activates dk-disks, which causes an automount attempt on internal hard disks.
> This doesn't happen if dk-disks is already running.

The desktop automounter actually should attempt to automount even if when devkit-disks is running. This is probably due to the GIO volume monitor implementation (gvfs-gdu-volume-monitor) incorrectly setting the flag for g_volume_should_automount() based on the :device-detection-time and :device-media-detection-time properties.

Worth looking into whether the bug is in GVfs (interpreting the values wrong), devkit-disks-daemon (setting the values wrong) or both...

As noted in comment 4, however, there should be no user interaction during automounting at startup. This means

 1. No "LUKS Unlock Volume" password dialogs etc.
 2. No error dialogs if an operation invoked during start-up triggers
    an error.
 3. No dialogs from PolicyKit

The first two are handled by Nautilus' automounter by respectively passing in NULL for the GMountOperation (meaning "no user interaction" requested) and also avoiding showing error dialogs for these operations. I believe this is working mostly fine.

The latter is more tricky to fix and the reason it is not fixed is that it's not apparent to me what the best way to fix it is. Basically, with the move to the new PolicyKit version all authentication dialogs happen out-of-band so to speak. For some background see the last half of this mail

http://lists.freedesktop.org/archives/polkit-devel/2009-May/000124.html

So, basically, right now devkit-disks-daemon will always pass in the POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION flag when checking authorizations. Meaning that any call to FilesystemMount() might trigger an authentication dialog.

What happens on GNOME startup is that the desktop automounter attempts to mount all volumes. So if you have a system-internal volume the default configuration will require authentication to mount it. So you see the polkit authentication dialog at start-up. That's a bug.

There are two ways to fix this

 1. If GMountOperation is NULL (meaning no user interaction is requested)
    then the gdu volume monitor could pass a "no_auth_interaction" flag
    to the FilesystemMount() method on devkit-disks (and we'd honor that
    by not passing POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION
    to polkit.

 2. Since gdu-gvfs-volume-monitor is a separate process, it could call into
    the polkit authority to signal that requests from this process should
    never trigger authentication dialogs even if the mechanism (devkit-disks)
    passes POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION

I'm leaning more towards option 1. and also changing _all_ operations on devkit-disks to take an array of option strings (most of them do already, it's a great way to have some degree of extensibility) so you can always pass "no_auth_interaction" for any operation.

Thoughts?

FWIW, I've filed http://bugzilla.gnome.org/show_bug.cgi?id=587981 in the GNOME bugzila to track the GNOME side of this.

> This is quite a nasty usability issue on inst...

Read more...

> I don't get any add events from devkit-disks-daemon using 'devkit-disks
> --monitor', only some 'change' event which is correct since we read ATA SMART
> data async on startup. It would be a bug to get 'add' events on coldplug, sure.

This is a little tricky, I can't use --monitor, since this already autospawns devkit-disks-daemon and generates those add/change dk events (not udev events). The bug happens because/when gvfs gdu spawns dk-disks and thus seem to pick up these initial change events only.

If i kill -daemon and do "devkit-disks --monitor" I see nothing (also nothing in udevadm monitor).

> Please verify it's the same for you (and state the version - if see the bug,
> please also try with HEAD).

I'm using version 005, can also try with HEAD. But I'll read your followup posts first, thank you for these details!

(In reply to comment #6)
> > I don't get any add events from devkit-disks-daemon using 'devkit-disks
> > --monitor', only some 'change' event which is correct since we read ATA SMART
> > data async on startup. It would be a bug to get 'add' events on coldplug, sure.
>
> This is a little tricky, I can't use --monitor, since this already autospawns
> devkit-disks-daemon and generates those add/change dk events (not udev events).
> The bug happens because/when gvfs gdu spawns dk-disks and thus seem to pick up
> these initial change events only.
>
> If i kill -daemon and do "devkit-disks --monitor" I see nothing (also nothing
> in udevadm monitor).

Running 'devkit-disks --monitor', then killing the daemon should work - e.g. as soon as the daemon comes up, then the 'devkit-disks --monitor' will start picking up events again (you can verify this by e.g. 'echo change > /sys/block/sda/uevent' as root and watching the monitor process print out the event).

So if you are not seeing anything, it seems like no wrong 'add' events are being emitted.

Btw, another way to verify this is to use 'dbus-monitor --system' as root.

> > Please verify it's the same for you (and state the version - if see the bug,
> > please also try with HEAD).
>
> I'm using version 005, can also try with HEAD. But I'll read your followup
> posts first, thank you for these details!

005 shouldn't be much different than HEAD in this respect. The major bug-fix that might have changed behavior was this one

http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=3f8f7c0983f2a081e194ca3620500ed023bb9088

Binary package hint: devicekit-disks

When starting a GNOME session without dk-disks running already, gvfs D-BUS activates dk-disks, which causes an automount attempt on internal hard disks. This doesn't happen if dk-disks is already running.

I suspect it's due to dk-disks sending out "new volume" events during coldplugging.

Reproducer:

  ps ux|grep gvfs|awk '{print $2}'|xargs kill
  gvfs-mount -l

This does not trigger automounting. However, if this spawns dk-disks it happens:

  sudo killall devkit-disks-daemon
  ps ux|grep gvfs|awk '{print $2}'|xargs kill
  gvfs-mount -l

Martin Pitt (pitti) wrote :

This is quite a nasty usability issue on installed systems (since GNOME starts with a polkit auth dialog), and a potential data loss problem on the live system, since this auto-mounts all partitions without questions. This could potentially disrupt broken file systems, hibernated NTFS partitions, etc.

Changed in devicekit-disks (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → Triaged

>1. If GMountOperation is NULL (meaning no user interaction is requested)
> then the gdu volume monitor could pass a "no_auth_interaction" flag
> to the FilesystemMount() method on devkit-disks (and we'd honor that
> by not passing POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION
> to polkit.

I don't have a firm opinion on this one, but it sounds sane to me.

This will still be a little inconsistent, since live CDs would always automount internal drives (which I still consider a bad thing [1]), while installed systems wouldn't. But I'll get used to it . :-)

Thanks!

Martin

[1] Installers need to unmount them again, mounting takes time, and broken file systems really shouldn't be automounted r/w without your consent, it only makes things worse (and you might have booted a live system to repair exactly that). IMHO your huge internal disks should be automounted on demand when you need them, i. e. when you click on the drive icon. It shouldn't really be so much different from the user's perspective when the drive is mounted (at session startup or when you open it in nautilus), but it would avoid lengthy and expensive, and potential dangerous mount processes at session start.

> Running 'devkit-disks --monitor', then killing the daemon should work

confirmed. No events at all when gvfs starts up, so it seems to be a bug in gvfs.

(In reply to comment #8)
> [1] Installers need to unmount them again, mounting takes time, and broken file
> systems really shouldn't be automounted r/w without your consent, it only makes
> things worse (and you might have booted a live system to repair exactly that).

So maybe live systems should just turn off automounting. Or have a special option in the bootloader to do that. And if people are doing "forensic live-cds" they definitely want to do that. And they can.

Either way, the presumption that automounting stuff "makes things worse" is in my view just a bad excuse for broken file system drivers. In fact, it's better to expose and fix these drivers than try to avoid not triggering bugs.

If OS vendors don't want this behavior for certain versions of their OSes (like Red Hat's RHEL, SUSE's SLES or Canonical's Ubuntu LTS relases) it's relatively straightforward to patch things the way you want them. I just don't think it's something we want in the upstream sources where we are supposed to be moving things forward, not ensuring maximum compatibility.

(And, my gods, yes, some file systems are somewhat broken. When mounting, say, ext3 in read-only mode it plays back the journal triggering writes. You can argue both ways about this but my view is that it's mostly wrong to do this by default.)

(Btw, another thing is that the desktop bits should probably run fsck (via devkit-disks) before mounting anything. But that's a separate issue and should be filed agains gvfs in the gnome bugzilla.)

> IMHO your huge internal disks should be automounted on demand when you need
> them, i. e. when you click on the drive icon. It shouldn't really be so much
> different from the user's perspective when the drive is mounted (at session
> startup or when you open it in nautilus),

We can't really do this since it will break autorun and other things like that. Also, you are only referring to the UI, keep in mind the APIs are stateful and has a notion of mounted/unmounted. So it won't work.

Do note that the file manager, file chooser and panel Places UI does work mostly like this though. E.g. you click an icon and the experience is the same whether the the underlying mount is mounted or not.

> but it would avoid lengthy and
> expensive,

Mounting happens asynchronously so this "lengthy process" [sic] isn't really visible to anyone nor anything to worry about.

> and potential dangerous mount processes at session start.

See above.

OK, you convinced me wrt. automount. :-)

So, to summarize:

 - gvfs needs to get fixed to always automount when starting the gdu monitor, not just when it triggers DK-disks. This is gnome #587981

 - DK-disks needs to grow a no_auth_interaction flag (this bug)

 - gvfs needs to pass that flag on startup (also above gnome bug?)

Thanks!

(In reply to comment #11)
> OK, you convinced me wrt. automount. :-)

Cool, I'm glad about that. Automounting / policy stuff is really tricky and hard to get right so am happy the current solution works for more than me!

> So, to summarize:
>
> - gvfs needs to get fixed to always automount when starting the gdu monitor,
> not just when it triggers DK-disks. This is gnome #587981

Right.

> - DK-disks needs to grow a no_auth_interaction flag (this bug)

Yeah, I'll add that soon.

> - gvfs needs to pass that flag on startup (also above gnome bug?)

Yup, let's handle it here.

FWIW, I'm currently waiting for alexl to review a huge invasive GVfs patch (bgo #587484) (this is also what is blocking getting your hal->gudev patches in). Then I'll fix up the gdu bits of gvfs (there are some other bugs that needs fixing too) to work according to what is outlined in this bug.

It will require new DKD and gdu releases - but should be able to get this done this or next week. Then after all that hopefully most desktop storage bugs, at least those bugs requiring GLib, DKD or gdu changes, should be fixed and we can move to bugfix mode for the gvfs-gdu bits after that. Which is probably a good thing as this is a major change...

So, yeah, lots of stuff happening, sorry if it's all a bit confusing!

Cheers,
David

Changed in devicekit:
status: Unknown → Confirmed

> > - gvfs needs to pass that flag on startup (also above gnome bug?)
>
> Yup, let's handle it here.

Argh, I meant "there", not "here". Sorry about that.

Martin Pitt (pitti) on 2009-07-07
summary: - internal partitions get automounted on startup
+ inconsistent automounting on startup
Changed in gvfs:
status: Unknown → Confirmed
Noel J. Bergman (noeljb) wrote :

Martin,

Is this also responsible for the nasty auto-mounting behavior detailed in Bug 412449? The primary focus of Bug 412449 is on the remove instead of umount behavior, but I also detailed how the volumes got mounted in the first place.

FYI, as noted in Bug 412449, when an external drive is connected using eSATA, the user is prompted that authentication is required to mount volumes, but when the same drive is connected over USB, all partitions are automatically mounted without requesting authentication.

Vish (vish) wrote :

Adding papercut task from duplicate.

Changed in hundredpapercuts:
importance: Undecided → High
milestone: none → round-10
status: New → Triaged
Michael Helmling (supermihi) wrote :

A simple workaround for those that are to annoyed by this bug should be to add the affected drives to /etc/fstab with the "noauto" option.

Noel J. Bergman (noeljb) wrote :
Download full text (4.1 KiB)

In my view, auto-mounting is inherently more complex than has been addressed, and the current handling is flawed, more so in Karmic compared to previous versions (or to Fedora 11, which also uses DeviceKit).

Due to the challenges, this comment is longish. To avoid burying an important point, I'll state it up front, rather than at the end.

*****
As challenging as the auto-mounting problem is, one policy would be really useful, and would allow us to separate out the complex cases from the common one. But how would you express and implement a policy that if there is a SINGLE partition, auto-mount IT; if there are MULTIPLE partitions, auto-mount NONE?
*****

As for auto-mounting issues, David Zeuthen explained elsewhere that "Nautilus doesn't treat non-removable different from removable when it comes to mounting file systems. [If] there's a mountable filesystem on a device, it is mounted. If you don't like automounting, turn it off in Nautilus."

ON or OFF is a pretty coarse-grained situation. :-) Users may start up with internal drives and external drives, or not, at any given instance, and want different policies. OK, so let's use /etc/fstab? How do you describe an entry in /etc/fstab to ignore a partition without having to describe details about it, such as UUID and file system that could change?.

Let's make it even more fun. David explained the behavior that I have seen related to differential treatment of the same drive depending on whether it is attached via eSATA or USB, "authorization is different depending on whether the device is considered system-internal or not." So for the SAME partition, we now have different interpretations for auto-mounting, depending on connector, despite the fact that it is removable and hot-pluggable in all cases.

Now lets consider scenarios from my own systems:

  A) An internal drive has multiple distro partitions and shared partitions. I only want the partitions I explicitly state that I want mounted. Karmic now tries to mount everything if auto-mounting is not turned off, which means turned off for everything. I should NOT have to edit /etc/fstab to exclude partitions, but since we now do, that should have been addressed as part of the install process, and a GUI provided to the end user.

  B) I attach USB, eSATA, or docked drives that have MULTIPLE partitions, and I do NOT want them automounted when connected. As before, Karmic attempts to mount them all, with or without authorization depending upon connector type. And, as noted in Bug 412449, when I click to unmount one, Karmic removes the entire device (again, depending on connector type). Hopefully, upstream will implement the proposals to separate drive and volume in the GUI.

  C) I attach various SDHC and USB drives with single partitions. I do want the partition mounted upon connect, *BUT* I may also want to specify mount options, such as the "noatime" option in the /etc/fstab example below. Are you proposing that I have an entry in fstab for every jump drive? David made a suggestion about using /etc/fstab with /dev/disk/by-path, but I tried that and observed that given:

   /dev/disk/by-path/pci-0000:15:00.2-part1 /media/SD...

Read more...

komputes (komputes) wrote :

I can confirm that in Karmic, every time I start a session from boot I get prompted for my password again to mount an internal disk/partition that I never asked to have mounted. If we are to mount partitions at boot, should we not have a way of configuring them (with options like passwd, nopasswd, mount at boot, don't mount at boot, custom mountpoint)

The system tries to mount another drive/partition. I see many issues with this:

1) window is above all others by default
2) user never requested this be mounted at boot/session-start (not in /etc/fstab)
3) there is no way to have it go away or mark as authorize for always (i.e. never ask me again)
4) it does not ask to mount any other partitions, it picks one and sticks to it

Attached is a picture of this authenticate dialog which is displayed every session-start. I also get a similar one when trying to eject a video DVD.

Vish (vish) wrote :

This seems more of a bug than a papercut [not a design flaw]
For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

Changed in hundredpapercuts:
milestone: round-10 → none
status: Triaged → Invalid

It looks as if the DK-D side of this is fixed in 006?

     Make FilesystemMount() accept an 'auth_no_user_interaction' option

Martin Pitt (pitti) wrote :

DK-Disks now provides the necessary support for this:

devicekit-disks (006-0ubuntu1) karmic; urgency=low

  * New upstream version:
    - Add a way to spin down drives
    - Fix segfault when starting a Linux MD array
    - Fix polling process title and turn off noisy debugging spew
    - Pass size of buffer to avoid Z_BUF_ERROR when compressing ATA SMART blob
    - Add --poll-for-media option to devkit-disks(1)
    - Work around media detection problems
    - Move implementation of DrivePollMedia into a separate process
    - Move data files into a separate directory
    - Misc fixes for optical disc detection
    - Fix up ATA SMART detection
    - Add Device:drive-is-rotational property
    - Add LinuxMdCreate method
    - Rely on the disk to spin itself down
    - Require latest libatasmart
    - Fix up object path mapping
    - Bug 23309 – Udev rules probe floppy drives when they shouldn't
    - Add a new :device-presentation-nopolicy property
    - Ignore loop and ram devices for now
    - Make FilesystemMount() accept an 'auth_no_user_interaction' option
    - Bug 23235 – Cannot mount disc with / (slash) in label
    - Hide recovery, boot, and hidden partitions from desktops
  * Drop debian/patches/*: All applied upstream.

 -- Martin Pitt <email address hidden> Sun, 23 Aug 2009 21:20:47 +0200

Now gvfs needs to use the auth_no_user_interaction option.

Changed in gvfs (Ubuntu Karmic):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → Triaged
Changed in devicekit-disks (Ubuntu Karmic):
status: Triaged → Fix Released
Nicolò Chieffo (yelo3) wrote :

Is this completely fixed or should we wait for another fix?

Vish (vish) on 2009-08-25
affects: hundredpapercuts → null
Vish (vish) wrote :

Yeah same question as Nicolo,
Right now for a partition mount i'm having to enter the password and it shows the icon in the notification area , which has a timeout !
So if i mount another partition before the timeout , i dont have to enter a password... else it again prompts for a password!

or is that a separate bug?

to be removed (liw) wrote :

We still need to wait for changes to gvfs to get this bug fixed.

(In reply to comment #14)
> It looks as if the DK-D side of this is fixed in 006?
>
> Make FilesystemMount() accept an 'auth_no_user_interaction' option
>

Yup, and the gvfs bit is here:

http://git.gnome.org/cgit/gvfs/commit/?id=3c9e828938625a88f71969c129a0972276b8c99e

Martin Pitt (pitti) wrote :
Changed in gvfs (Ubuntu Karmic):
status: Triaged → Fix Committed
Durand D'souza (durand1) wrote :

Great!

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.3.5-0ubuntu2

---------------
gvfs (1.3.5-0ubuntu2) karmic; urgency=low

  * Add 00git-noninteractive-mounting-at-startup.patch: Do not attempt to
    mount drives at startup which need authentication. (LP: #396448)
  * debian/control: Bump libgdu-dev requirement for above patch.

 -- Martin Pitt <email address hidden> Mon, 31 Aug 2009 19:14:04 +0200

Changed in gvfs (Ubuntu Karmic):
status: Fix Committed → Fix Released
Changed in devicekit:
status: Confirmed → Fix Released
komputes (komputes) wrote :

Now that this is fixed what is the expected behavior?

I still get prompted for a password when I boot. I now get prompted for a password when mounting a secondary disk, and I'm in the sudoers file as NOPASSWD.

komputes [2009-09-01 3:42 -0000]:
> Now that this is fixed what is the expected behavior?

You shouldn't get this password prompt at session startup any more.
But of course you should still get it when you manually attempt to
mount an internal disk in GNOME.

Works fine here.

> I still get prompted for a password when I boot.

When exactly? What does the dialog say?

> I now get prompted for a password when mounting a secondary disk,
> and I'm in the sudoers file as NOPASSWD.

Mounting has not been done through sudo since at least Breezy (5.10),
so sudoers won't have an effect. "secondary disk" -> internal hard
disk? Then that's correct and expected. We have never allowed the user
to mount an internal disk without authorizing with his password.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Vish (vish) wrote :

Hmm... for some reason i cant get the update > gvfs (1.3.5-0ubuntu2) ?
Its been ~15 hrs , why is it not yet available?

Vish (vish) wrote :

Also, after update to gvfs (1.3.5-0ubuntu2), which fixes the boot prompt.
How to set the gvfs to not prompt on every mount?
Previously , this could be set the authorizations for hal/storage , In System > Administration > Authorizations. Now where do to set these permissions? [To not prompt on every partition mount] Is there any similar option?

Martin Pitt (pitti) wrote :

mac_v [2009-09-01 8:37 -0000]:
> Hmm... for some reason i cant get the update > gvfs (1.3.5-0ubuntu2) ?
> Its been ~15 hrs , why is it not yet available?

Sorry, it failed to build due to some autoconf madness (it built fine
locally). Need to investigate.

komputes (komputes) wrote :

Hi Martin,

I am using gvfs 1.3.5-0ubuntu3 and devicekit-disks 006-0ubuntu3 in karmic and I still get the same dialog password prompt I attached to comment #6.

http://launchpadlibrarian.net/30493532/dialog_at_session-start.png

It is asking a password for the secondary internal disk, although I never asked it to be mounted at boot.

Martin Pitt (pitti) wrote :

komputes [2009-09-01 19:58 -0000]:
> I am using gvfs 1.3.5-0ubuntu3 and devicekit-disks 006-0ubuntu3 in
> karmic and I still get the same dialog password prompt I attached to
> comment #6.

Stupid question, but did you reboot after those updates? If you
restart your session seldomly (suspend, etc.), you might still have a
previous binary running?
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt (pitti) wrote :

mac_v [2009-09-01 8:43 -0000]:
> Also, after update to gvfs (1.3.5-0ubuntu2), which fixes the boot
> prompt. How to set the gvfs to not prompt on every mount?
> Previously , this could be set the authorizations for hal/storage ,
> In System > Administration > Authorizations. Now where do to set
> these permissions? [To not prompt on every partition mount] Is there
> any similar option?

Unfortunately there is no GUI equivalent for the old "Authorizations"
dialog yet. You should be able to change it in configuration files,
see man pklocalauthority. (Haven't tried myself yet, though).

komputes (komputes) wrote :

Yes, I updated last night (to the versions specifies in comment #20) and rebooted this morning. I still get prompted to enter a password for the secondary internal drive at the beginning of the gnome session.

Martin Pitt (pitti) wrote :

komputes [2009-09-01 21:25 -0000]:
> Yes, I updated last night (to the versions specifies in comment #20) and
> rebooted this morning. I still get prompted to enter a password for the
> secondary internal drive at the beginning of the gnome session.

OK, so this requires some deeper debugging then, as it is apparently a
different root cause than the one that everyone else had and which was
fixed now.

Please try the following command sets in the given order and check
which ones cause this dialog box to appear:

1.

   killall nautilus

2.

  kill `ps ux|grep usr/lib/gvfs|awk '{print $2}'`
  gvfs-mount -l

3.

  kill `ps ux|grep usr/lib/gvfs|awk '{print $2}'`
  killall nautilus

4.

 sudo killall devkit-disks-daemon
 killall nautilus

5.

  sudo killall devkit-disks-daemon
  kill `ps ux|grep usr/lib/gvfs|awk '{print $2}'`
  killall nautilus

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

komputes (komputes) wrote :

Martin,

I would say the fix is confirmed. The versions of the packages in comment #20 are still the same.

I ran updates yesterday and it seemed to fix the issue. I do not get a dialog at the start of the session for a disk I did not ask to mount. If I mount the drive manually I am still asked for a password, and I am not too sure how to suppress that. I have added the partition to /etc/fstab for now, which mounts the partition without needing the password. Please let me know if running these or other commands is still needed on my part.

Thank you.

Martin Pitt (pitti) wrote :

komputes, thanks for checking again. If it's working for you, no need to exercise the debugging steps.

Jake (flare88) on 2009-11-13
Changed in devicekit-disks (Ubuntu Karmic):
status: Fix Released → Fix Committed
Steve Langasek (vorlon) wrote :

please don't change the status of bugs without explanation.

Changed in devicekit-disks (Ubuntu Karmic):
status: Fix Committed → Fix Released
tags: added: iso-testing
pvdeynse (vandeynse) on 2010-04-15
description: updated
Changed in devicekit:
importance: Unknown → Medium
Changed in gvfs:
importance: Unknown → Medium
status: Confirmed → Fix Released
Changed in devicekit:
importance: Medium → Unknown
Changed in devicekit:
importance: Unknown → Medium
Curtis Hovey (sinzui) on 2011-11-11
no longer affects: null
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.