GNOME Bugzilla – Bug 771740
gvfs-udisks2-volume-monitor activates autofs mountpoints
Last modified: 2018-09-21 18:02:23 UTC
I have an autofs + sshfs mount set up in /etc/fstab (requires systemd): /path/to/sshfs#user@host.local:/ /home/user/mnt/host.local fuse noauto,_netdev,allow_other,x-systemd.automount,ssh_command=/path/to/ssh_as_user 0 2 where "/path/to/ssh_as_user" is: #!/bin/sh exec "/path/to/sudo" -i -u "user" "/path/to/ssh" "$@" The problem is that gvfs-udisks2-volume-monitor continuously activates the autofs mountpoint: systemd[1]: Set up automount home-bfo-mnt-ul30a.local.automount. systemd[1]: home-bfo-mnt-ul30a.local.automount: Got automount request for /home/bfo/mnt/ul30a.local, triggered by 2225 (gvfs-udisks2-vo) systemd[1]: home-bfo-mnt-ul30a.local.automount: Got automount request for /home/bfo/mnt/ul30a.local, triggered by 2225 (gvfs-udisks2-vo) systemd[1]: home-bfo-mnt-ul30a.local.automount: Got automount request for /home/bfo/mnt/ul30a.local, triggered by 2225 (gvfs-udisks2-vo) systemd[1]: home-bfo-mnt-ul30a.local.automount: Got automount request for /home/bfo/mnt/ul30a.local, triggered by 2225 (gvfs-udisks2-vo) systemd[1]: home-bfo-mnt-ul30a.local.automount: Got automount request for /home/bfo/mnt/ul30a.local, triggered by 2225 (gvfs-udisks2-vo) systemd[1]: home-bfo-mnt-ul30a.local.automount: Got automount request for /home/bfo/mnt/ul30a.local, triggered by 2225 (gvfs-udisks2-vo) systemd[1]: home-bfo-mnt-ul30a.local.automount: Unit entered failed state. This is undesirable. On the GVFS mailing list I was informed about the "x-gvfs-hide" mount option, or to put the autofs mountpoint somewhere else, where GVFS doesn't consider to auto-mount. But still it seems like a bad idea to have the current behaviour as default. (Also, for native systemd .mount and .automount units, the "x-gvfs-hide" mount option doesn't work, presumably because GVFS only looks in /etc/fstab and not in the systemd units.) Best regards, Bjørn Forsman
Thanks for your bug report. The following code determines which mounts are shown and which are not: https://git.gnome.org/browse/gvfs/tree/monitor/udisks2/gvfsudisks2volumemonitor.c#n607 There is a logic, which tries to determine which mount points are user interesting and which are not. User interersting mounts are usually in "/media", "/run/media/$USER", "$HOME", or has "x-gvfs-show" option. Different paths cause that mounts aren't considered as interesting, same for "x-gvfs-hide" option. User interesting mounts are usualy automounted by gnome-shell, if "noauto" option is not specified. See "should_automount" property in "gvfs-mount -li" output. I don't think that we can just generally ignore all autofs mounts, it could be handy to have some of them in Nautilus sidebar, however we have to be sure that GVfs doesn't cause automounting/activating of them... Let's imagine your /home/user/mnt/host.local mount point. This mount isn't hidden, because the mount point is considered as user interesting (this is intended). I think this is right and you can change it by "x-gvfs-hide". It should not be also automounted by the gnome-shell, because "noauto" is used. I wonder why you see the following (this isn't intended): systemd[1]: home-bfo-mnt-ul30a.local.automount: Got automount request for /home/bfo/mnt/ul30a.local, triggered by 2225 (gvfs-udisks2-vo) I configured one nfs mount with "x-systemd.automount" option and one using the ordinary "/etc/auto.master" file, I can see them in the UI, however they are not automounted. I see only the following automounts, but it seems they are not caused by GVfs: systemd[1]: media-test.automount: Got automount request for /media/test, triggered by 3900 (pool) Can you please attach output from "gvfs-mount -li" and "/etc/mtab"? (GVfs is not looking only in "/etc/fstab", it uses GLib for listing available mounts, I think it is based on "/etc/mtab" at this point. Therefor, GVfs should see mount options specified by "Options=" directive in the unit file... can you please attach your unit file and output from "/etc/mtab" if it doesn't work for you?)
> GVfs should see mount options specified by "Options=" directive in the unit file... Right. I cannot reproduce the bug at the moment, presumably I did a mistake earlier. "Options=x-gvfs-hide" works in the .unit file now. (I'll create the attachments now.)
Created attachment 336102 [details] Output of "gvfs-mount -li"
Created attachment 336103 [details] Copy of /etc/mtab
I am finally able to reproduce it and see what is wrong with autofs. The difference with autofs in comparison with ordinary mounts is that the mount always exists (you can see it in "/etc/mtab"), but do not have to be really mounted. However, gvfs-udisks2-volume-monitor thinks that it is really mounted if the mount exists... Consequently, the following code is called which looks for some files on that mounts (e.g. autorun.inf, .xdg-volume-info), which causes the unwanted automounts for autofs... https://git.gnome.org/browse/gvfs/tree/monitor/udisks2/gvfsudisks2mount.c#n287 Hmmmm, we can skip this functionality for autofs, but maybe the right solution is really to ignore all the autofs mounts :-/
> However, gvfs-udisks2-volume-monitor thinks that it is really mounted if the mount exists... I guess that's the problem right there. It shouldn't consider an autofs mountpoint as a "mount". It should wait until the real filesystem is mounted: $ mount | grep ab9.local systemd-1 on /home/bfo/mnt/ab9.local type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct) $ ls -l /home/bfo/mnt/ab9.local total 64 drwxr-xr-x 1 root root 4096 sep. 18 15:17 bin [...] $ mount | grep ab9.local systemd-1 on /home/bfo/mnt/ab9.local type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct) bfo@ab9.local:/ on /home/bfo/mnt/ab9.local type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
Created attachment 336347 [details] [review] udisks2: Use device path to match mount points also Mount path is used to match mount points currently, however device path should be used also in order to be sure it is really corresponding mount point. Same mount path can be used for multiple mount entries (it is also used e.g. for autofs). $ mount | grep /media/test systemd-1 on /media/test type autofs ... localhost:/home/oholy on /media/test type nfs4 ...
Created attachment 336348 [details] [review] udisks2: Filter out system mounts System mounts (i.e. autofs) can be considered as user interesting currently if mount paths are user interesting. However, we should not handle those mounts as GMounts, because consequently redundant mounts are offered by volume monitor. It also causes automounts of autofs filesystems. $ mount | grep /media/test systemd-1 on /media/test type autofs ... localhost:/home/oholy on /media/test type nfs4 ...
Attachment 336347 [details] pushed as b773698 - udisks2: Use device path to match mount points also Attachment 336348 [details] pushed as 078588c - udisks2: Filter out system mounts
Ondrej, thank you!
https://git.gnome.org/browse/gvfs/commit/?id=b77369832fd6fb97e1f036998663f2488ff15022 The above commit from this issue seems to be causing regressions as seen in these two gvfs bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=772961 https://bugzilla.gnome.org/show_bug.cgi?id=772942
Yes, you are right, unfortunately. I've already reverted the patches causing various issues (Bug 772942, Bug 772961, Bug 772867).
Review of attachment 336348 [details] [review]: should_include() is never called and thus x-gvfs-show is not handled...
Review of attachment 336347 [details] [review]: It doesn't work with LABEL=, UUID=...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/287.