Bug 813069 - Devices are not mounted at login time
Devices are not mounted at login time
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gvfs (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-16 15:50 EDT by Jonathan Kamens
Modified: 2015-03-03 18:05 EST (History)
8 users (show)

See Also:
Fixed In Version: gvfs-1.12.2-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-02 00:57:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan Kamens 2012-04-16 15:50:30 EDT
The move from /media to /run/media/$USER has resulted in the creation of the following bug....

1. Insert a removable device.
2. Wait for it to be mounted.
2. Reboot your system.
3. Log back in again.
4. The device is invisible.

This is not expected behavior. This is not intuitive behavior. This is not the behavior of any other OS currently in existence, as far as I know.

If I log in, I expect the removable devices in my system to be visible to me. They were visible in F16. They whould be visible in F17.
Comment 1 David Zeuthen 2012-04-16 17:12:00 EDT
(In reply to comment #0)
> The move from /media to /run/media/$USER has resulted in the creation of the
> following bug....
> 
> 1. Insert a removable device.
> 2. Wait for it to be mounted.
> 2. Reboot your system.
> 3. Log back in again.
> 4. The device is invisible.
> 
> This is not expected behavior. This is not intuitive behavior. This is not the
> behavior of any other OS currently in existence, as far as I know.
> 
> If I log in, I expect the removable devices in my system to be visible to me.
> They were visible in F16. They whould be visible in F17.

I think you are confused. The main change is that GNOME does not auto-mount devices at login anymore and that's not a bug, it's actually by design. And the device is not "invisble" just because it's not mounted - you can get to it by clicking its icon in the file manager (nautilus / Files) or the file chooser.

If you insist on the device being mounted at OS start-up, you can add an /etc/fstab entry (the "Edit Mount Options" dialog of the Disks can be used to do that).

There is no bug here so closing NOTABUG.
Comment 2 Jonathan Kamens 2012-04-16 17:31:01 EDT
Your logic for why this is not a bug is circular.

You are claiming that it is not a bug because the behavior is by design. I am saying that it is that design that is buggy.

Windows: Log in. Open cmd window "cd d:". Oh, look, there are my files!

Mac OS: Log in. Open terminal window. "cd /Volumes/...". Oh, look, there are my files!

F17 GNOME: Log in. Open terminal window. Where are my files?

It strains credulity to say that it makes any sense whatsoever for a device to be mounted when I am logged in, and then if I immediately log out and log back in again, it's no longer mounted. There is a huge infrastructure built into GNOME to restore a user's session to how it was when he logged out. Why this should be any different is beyond me.

I know the etiquette, so I'm not going to reopen the ticket even though I think this is an incredibly stupid, non-intuitive design change which is just plain wrong. It'll be interesting to see how many dupes, CC's and votes this ticket gets after F17 is released.
Comment 3 David Zeuthen 2012-04-16 17:57:24 EDT
As I explained, GUI users can easily access their files simply by using the UI (that is: the file manager or the file chooser) even when the device is not mounted. IOW: they're fine. This is by far most GNOME users.

Non-GUI users with needs to access a device at a known path at log-in time ("experts" or "Linux hobbyists" or whatever), such as yourself... you guys are expected to actually know enough about the system to be able to use things like the /etc/fstab file... which has been around since the dawn of time ... or write a script to mount your devices... or whatever. Note that /etc/fstab also allows you to precisely control the mount path, mount path permissions and mount options. It allows you to use constructs such as the /dev/disk/by-* symlink forst and so on.

Also: The Disks application even includes an UI for editing /etc/fstab entries, see http://davidz25.blogspot.com/2012/03/simpler-faster-better.html and http://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt for more details about what you can control.

You remarks and use words is not exactly helping your cause here. Good luck.
Comment 4 Stijn Hoop 2012-04-17 02:58:04 EDT
David,

do you seriously think that "finding the device" is discoverable? I hate to bring up such cliches as Aunt Tilly, but I am with Jonathan here: this is not only different from the previous Fedora releases, but also inconsistent with other operating systems.

The users that I support for a living look for their files. They are not Linux hobbyists or experts, they are mathematicians wanting to use a Latex and math friendly environment but they do not know much about Linux. If they happen to plug in their USB stick but only then discover that they had not in fact actually turned on their PC, now they have to know that the device is actually "LEXAR 8 GB" instead of "SONY SMARTCARD READER". Do you think that is the case you want to support?
Comment 5 David Zeuthen 2012-04-18 17:41:30 EDT
OK, I think you guys changed my mind. I mean, it doesn't really make things worse for anyone if we automount at login time and since it arguably makes things a little better for some, let's just do it and avoid this behavioral change. I fixed the bug upstream here

 http://git.gnome.org/browse/gvfs/commit/?id=e30a67f3215d829e95ee7e358c67af7d67635fe8

I'm reopening and reassigning to GVfs ... the GVfs package maintainers can close this bug once that patch lands downstream.
Comment 6 David Zeuthen 2012-04-18 17:42:28 EDT
Adjusting summary to be a bit more accurate
Comment 7 Bill Nottingham 2012-04-18 18:04:22 EDT
Got mid-air-collisioned, but for reference:

Issues with the (prior) design:

1) By placing them in a user-specific directory, it implies that mounts are
tied to the session. However, they are not - they persist beyond it until
reboot. This leads to inconsistency - you log in once, plug in a device. Then,
if you log out and log back in a week later, the device is there, when it
wouldn't be if all you did was reboot the machine in the interim.

2) /run/media/user/$foo is odd, given that we already have /run/user/$foo
waiting to be used. (This ties into #1, although not directly related.)

3) The disks default for mount point naming doesn't match the gvfs/udisks2
default for in session

4) It's inconsistent with other uses of detachable hardware. For this, if it's
coldplugged (booted with attached), it's visible-in-gvfs-but-inactive in all
sessions unless someone activates it. For other detachable hardware, such as a
USB webcam, it's immediately active when booted coldplugged. (I understand
there are reasons why that works better, but it's still inconsistent.)

It would seem to me a better design would be for it not to automount at all,
but on both hotplug and coldplug to be shown as a device in the notification
area much as it is now, with the same options that are normally shown with
hotplug. In this case 'Open With Files' would mount and then open, rather than
operating on an already mounted filesystem.
Comment 8 David Zeuthen 2012-04-18 18:23:43 EDT
(In reply to comment #7)
> 2) /run/media/user/$foo is odd, given that we already have /run/user/$foo
> waiting to be used. (This ties into #1, although not directly related.)

We actually started out using /run/user/$foo/media but... there's a bunch of security issues with having a privileged process mount a device in a directory that is under the control of the untrusted process we mount on behalf of...

> It would seem to me a better design would be for it not to automount at all,
> but on both hotplug and coldplug to be shown as a device in the notification
> area much as it is now, with the same options that are normally shown with
> hotplug. In this case 'Open With Files' would mount and then open, rather than
> operating on an already mounted filesystem.

That's an interesting design (and I think, generally something that would make the unix-diehard-beards put a contract on you...). However, part of the user interaction requires sniffing the files on the device ... for example to see if there are photos on it and if so, prompt the user to import them. Of course, we could then unmount the device _right after sniffing but..
Comment 9 Adam Williamson 2012-04-18 19:13:41 EDT
Plus, it's still not very nice for the case where I just want to plug in a USB stick and then do something with it at the console. It gives me the choice between having the device mounted but also having a Nautilus window open which I didn't want, or having no extraneous Nautilus window, but not having the device mounted...

It really is kind of annoying to plug in a stick, do 'ls /media/<tab>', and get crickets.

Thanks for the change, David.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 10 Fedora Update System 2012-04-27 09:37:26 EDT
gvfs-1.12.2-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/gvfs-1.12.2-1.fc17
Comment 11 Fedora Update System 2012-04-27 19:35:14 EDT
Package gvfs-1.12.2-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gvfs-1.12.2-1.fc17'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-6873/gvfs-1.12.2-1.fc17
then log in and leave karma (feedback).
Comment 12 Fedora Update System 2012-05-02 00:57:04 EDT
gvfs-1.12.2-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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