GNOME Bugzilla – Bug 536292
user-mountable nfs filesystems are not showing up in Computer view of nautilus
Last modified: 2009-12-21 20:04:53 UTC
Please describe the problem: When a nfs mount is defined in /etc/fstab with the option "user", an icon should appear in nautilus to access this volume, and let the user mount/unmount it. In Ubuntu Hardy which uses gvfs, it isn't the case (it use to work in gutsy, without gvfs). Without this, there's no way to access nfs volumes easily (you have to mount it in command line) Steps to reproduce: 1. Add a nfs mount with the "user" option 2. Look in "computer" view of nautilus Actual results: The volume doesn't appear Expected results: The volume should appear (so the user can mount the volume and browse it). Does this happen every time? yes Other information: The bug report for ubuntu : https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/195180
Created attachment 111982 [details] Content of /etc/mtab
Created attachment 111983 [details] Content of /etc/fstab
Created attachment 111984 [details] Content of /proc/mounts
Created attachment 111985 [details] Result of 'gvfs-mount -li'
*** Bug 536881 has been marked as a duplicate of this bug. ***
> Thanks for the bug report. This is likely due to the changes in the GVFS-Hal > backend, which we already have a duplicate for. ah sorry for duplicating :) > If some local drives are not showing up and their mountpoint is inside of > /media, then you should open another bug against GVFS-Hal and include the > output of lshal, gvfs-ls computer:///, your fstab, and other relevant > information. Thanks again. Hum, I'd like to bring one point that might have been overlooked with this change, as far as my understanding goes, /media is reserved for pluggable medias (usb sticks, cdroms, ...) while /mnt is reserved to "system" volumes, be it nfs, afs, coda (...) shares set by administrator, or other volumes on your disk that are always mounted and have no reason to show up under /media. The thing about computer:/// is that until 2.22 it would be a de facto shortcut to any or these volumes and I found it really cool. Please tell me if I'm unclear.
The rationale for that is explained here: http://bugzilla.gnome.org/show_bug.cgi?id=520736#c1
I read that a while ago and I even though I understand new users to linux will find it less disturbing, this is imho a regression in features that makes nautilus far less usable than it was since 2.4 or so (when I started using linux). To me the problem is not the default because like davidz said you/distros can add entries in fstab or hal to _hide_ volumes but there is no way to _show_ them afaict.
Absolutely agreeing, this was much more user-friendly before, now I have to explain "opening a console and entering 'mount /media/pictures'" instead of "just doubleclick on the 'pictures' Symbol in Computer". Would really like to see this agaun.
Dear all, I forgot to put this on the Gnome Hate wall at FOSDEM. However, I read the rationale in #520736 but I still don't understand if there is a way to have my NFS shares in "Computer" ready to be clicked and mounted. And yes, both shares have their mountpoint under /media, and it is enough a "mount /media/share" to have it mounted. Thanks for your help!
Hi, I would also be happy to get more information on this point, as despite my numerous tests, I have never been able to list NFS shares in computer:/// ALl of them have mountpoints in /media, I have tested with & without the user(s) mount options etc. Still, nothing shown... Cheers, Julien
I have just noticed that launching nautilus as root (using su-to-root) makes the NFS mounts appear in the nautilus window. It does also mount them automatically (which is not what I would like, but this must be quite easy to avoid using a correct hal policy). This hence means that it is a question of permissions, but I do not see what permissions I am missing! I have tried chmoding the mount point (just in case), without success. Cheers, Julien
Ah, one other thing: the NFS mounts appear with standard drive icons. That might help finding what is the clue
davidz: How is this supposed to work? The hal monitor only lists stuff that are availible from querying hal, and the NFS mounts are not availible there. Any ideas? Julien: The reason it works as root is because when doing the su you'll have not session dbus, so we're falling back to the non-hal volume monitor.
(In reply to comment #14) > davidz: How is this supposed to work? The hal monitor only lists stuff that are > availible from querying hal, and the NFS mounts are not availible there. Any > ideas? This is intentional, we don't generate any *GVolume* objects from entries in /etc/fstab. But we do generate *GMount* objects for mounted NFS file systems. The rationale, IIRC, for things being this way is that most NFS clients automount at boot or login time and there were some concerns that we would be screwing up stuff if we did. I can't remember the details though. We could do this if we wanted but it's just not the way it works right now.
Hi David, Thanks for your explanations. However, from a user point of view, I don't this is not the right thing to do. I do not mount my NFS shares at boot time because I have plenty of them and do only use them occasionally. More over, I use a laptop, which is not always connected to my network, but also at work etc. Should I try and automount all the shares even if I know for sure some won't be available? I don't think this is what a user would expect. Is there any chance that this could be turned into an option? By default, the current behavior could be kept, but if the option is changed, the fstab file would be inspected to find which NFS shares should be visible (but *not* auto-mounted)? Cheers, Julien PS : thank you as well Alexander for explaining why it does work as expected as root.
Or perhaps we could allow them in /media? Systemwide nfs mounts are generally put in /mnt.
Our downstream bug report in gentoo [1] also includes quite a few users in the same case Julien mentionned (myself included). For me, it would also be fine if nfs shares could be discovered through dns service discovery. [1] https://bugs.gentoo.org/show_bug.cgi?id=216286
Hi, Generally speaking I don't really want to rely on users setting up /etc/fstab, I don't think it's the right way to say "GVfs support NFS" much the same way we don't require that kind of magic for e.g. usb thumbdrives or FTP or SFTP mounts; it's just not a very good experience unless you're a hacker type that knows about /etc/fstab in the first place. So maybe it would be useful to think a bit more about the problem. (In reply to comment #17) > Or perhaps we could allow them in /media? Systemwide nfs mounts are generally > put in /mnt. How about having a gvfs backend for nfs? I mean, we wouldn't want to deal with the protocol per se, we'd just do a privileged helper that pokes the kernel to setup the mount (and creates/destroys the mount point as well); shouldn't be a lot of work...
(In reply to comment #19) > How about having a gvfs backend for nfs? I mean, we wouldn't want to deal with > the protocol per se, we'd just do a privileged helper that pokes the kernel to > setup the mount (and creates/destroys the mount point as well); shouldn't be a > lot of work... Btw, this would also fix the issues with having the user to specify things "user", "users" or "pam_console" to get this working. We'd lock the privileged helper down with PolicyKit (or maybe we don't lock it down at all, I haven't thought much about it).
I'm not sure how you mean this to work? If we're not showing the nfs mounts from fstab, how would the user ever mount a NFS mount, independent on exactly how the NFS filesystem is implemented. Either we show NFS mounts and let the user mount them or not, fiddling with another way to mount them is imho irrelevant to this question. And if we show them we need to let the user configure the list of availible mounts somewhere, and fstab would seem to be a good place (its after all where people have this configured already).
(In reply to comment #21) > I'm not sure how you mean this to work? If we're not showing the nfs mounts > from fstab, how would the user ever mount a NFS mount, Presumably the same way you deal with other network mounts: via network:// and bookmarks [1], not sure why this should be different from, say, sftp or smb mounts.. [1] : we still want better bookmarks and have a "[x] save as bookmark" in the "connect to server dialog" ... see bug 556040 for details
Where its displayed is not really the issue. Rather were we would get the data for this. NFS is generally not discoverable.
(In reply to comment #23) > NFS is generally not discoverable. Neither is FTP (for example). > Where its displayed is not really the issue. Rather were we would get the data > for this. So people just use "Connect to Server" or the address bar or whatever. My point is really that it's weird to treat NFS as a special case here. Btw, just shrugging and saying "NFS is not user discoverable" isn't really the best of responses. For example, OS vendors could take a cue from Apple's playbook and just advertise NFS servers using DNS-SD (Apple does this for at least SMB and I think other services you can export). But, anyway, back to reality. Alex, so are you suggesting that we should generate GVolume objects for user-mountable (e.g. option "user", "users", "pam_console", "group", "owner"; see the mount man page for more details) _and_ user-visible (e.g. mount point under the /media hierarchy) mounts? It does add some comfort for the small demographic using NFS and other mounts this way...
on nautilus-2.24 neither using /media instead of /mnt works for local filesystems : I added this line to mine /etc/fstab : /dev/sda1 /media/win ntfs-3g noauto,rw,user,users,codepage=850,iocharset=iso8859-15,utf8 0 0 using terminal I can mount/umount /media/win but in computer:// when /media/win is unmounted I cannot see the win Icon, I can see it only after a mount (using terminal) , and if I unmount it disappears again . For me it is a regression respect 2.22 . mine distribution is gentoo linux on amd64 arch .
davidz: I don't exactly disagree with you on the NFS discoverability, etc. But, we also have to live with what people want to do today. And a lot of people have defined NFS mounts that are not always mounted (e.g. they might be availible only in one place and this is a laptop). So, I guess I'm proposing more or less what you said. It seems useful for a common subset of linux users (the "experts" or what have you) and it doens't hurt people outside this subset.
(In reply to comment #26) > So, I guess I'm proposing more or less what you said. It seems useful for a > common subset of linux users (the "experts" or what have you) and it doens't > hurt people outside this subset. Sure, that sounds sensible. So basically we'd just generate generate GVolume objects for entries in user-mountable entries in /etc/fstab (that doesn't already have a block device). It's useful outside nfs too (things like fuse file systems). I can do this for the GVfs gdu monitor (don't think we need it for the GVfs hal monitor since this feature won't land until the next release). (Aside from that I think it would be nice to have a "real" nfs:// support in GVfs using the kernel driver. We could have something like an in-process GNfsFile (like GDaemonFile) class that handles IO for nfs:// URIs (no need to proxy it to a daemon). Then again, NFS is sorta a fringe filesystem to be using on the desktop but many people tell me NFS is much faster than anything else. So if it's not too much work we should probably do it...)
FWIW, I just added this feature to the gdu volume monitor http://cgit.freedesktop.org/~david/gvfs/commit/?h=gdu-volume-monitor&id=0f7a44dd0eac01f9783879af4ca3d3fe4a53af14 so this will land in the GVfs release for GNOME 2.28 (which will have the gdu volume monitor).
Thanks David! Can't wait to try it out!
Kudos to David for his work! Cheers, Julien
There is a bug report at <https://launchpad.net/bugs/229370> saying that in a certain situation USB sticks that are mounted with /etc/fstab don't show up in Places. After further digging we managed to find out that the entry doesn't show up in Gvfs(the GVolumeMonitor, acutally), but does show up in DeviceKit-disks. Could this be related to this bug, or more precisely: the patch that solved this bug?