Thanks for your bug report! Just to be sure, was the fstab same in F25?

It should be possible to use "x-gvfs-hide" mount option as a workaround.

Hmm, this is presumably duplicate of Bug 771740. However, I wonder why the mount with the path beginning with /boot is not ignored...

I am not able to reproduce it. Such mounts seem to be successfully filtered out based on the path thanks to the g_unix_is_mount_path_system_internal function:
https://git.gnome.org/browse/glib/tree/gio/gunixmounts.c#n220

Can you provide more info in order to figure out what triggered the automount?

(In reply to Ondrej Holy from comment #3)
> I am not able to reproduce it. Such mounts seem to be successfully filtered
> out based on the path thanks to the g_unix_is_mount_path_system_internal
> function:
> https://git.gnome.org/browse/glib/tree/gio/gunixmounts.c#n220

To be precise, /boot is filtered by this and /boot/efi by other filters in should_include:
https://git.gnome.org/browse/gvfs/tree/monitor/udisks2/gvfsudisks2volumemonitor.c#n607

(keep it simpler by just modifying /boot/efi mount point)

1. Using virt-manager, create a VM using UEFI firmware (edk2-ovmf)
2. Install Fedora-Workstation-Live-x86_64-25-1.3.iso using default path (autopartitioning).
3. At first boot following installation, modify the /etc/fstab such that the /boot/efi mount point's mount option includes "nofail,noauto,x-systemd.automount" save, and reboot.

Actual result:
/boot/efi is not automounted

[chris@f25h ~]$ sudo journalctl -b | grep automount
May 03 10:49:27 f25h.localdomain systemd[1]: Set up automount boot-efi.automount.


Repeat the above, using Fedora-Workstation-Live-x86_64-26-20170420.n.0.iso

Actual result:
/boot/efi is automounted.

[chris@f26h ~]$ sudo journalctl -b | grep automount
[sudo] password for chris: 
May 02 09:09:40 f26h.localdomain systemd[1]: Set up automount boot-efi.automount.
May 02 09:09:44 f26h.localdomain systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 1366 (packagekitd)
May 02 09:09:44 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 1366 (packagekitd)


This is consistent, but if I try to umount it, I get different results (maybe a race) on what process is triggering the automount:

[chris@f26h ~]$ sudo umount -v /boot/efi
[sudo] password for chris: 
umount: /boot/efi unmounted
[chris@f26h ~]$ sudo journalctl -b | grep automount
May 02 09:09:40 f26h.localdomain systemd[1]: Set up automount boot-efi.automount.
May 02 09:09:44 f26h.localdomain systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 1366 (packagekitd)
May 02 09:09:44 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 1366 (packagekitd)
May 03 11:04:55 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 1820 (gvfs-udisks2-vo)


[chris@f26h ~]$ sudo umount -v /boot/efi
umount: /boot/efi unmounted
[chris@f26h ~]$ sudo journalctl -b | grep automount
May 02 09:09:40 f26h.localdomain systemd[1]: Set up automount boot-efi.automount.
May 02 09:09:44 f26h.localdomain systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 1366 (packagekitd)
May 02 09:09:44 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 1366 (packagekitd)
May 03 11:04:55 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 1820 (gvfs-udisks2-vo)
May 03 11:05:25 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 2743 (gvfsd-trash)


[chris@f26h ~]$ sudo umount -v /boot/efi
umount: /boot/efi unmounted
[chris@f26h ~]$ sudo journalctl -b | grep automount
May 02 09:09:40 f26h.localdomain systemd[1]: Set up automount boot-efi.automount.
May 02 09:09:44 f26h.localdomain systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 1366 (packagekitd)
May 02 09:09:44 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 1366 (packagekitd)
May 03 11:04:55 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 1820 (gvfs-udisks2-vo)
May 03 11:05:25 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 2743 (gvfsd-trash)
May 03 11:05:58 f26h.localdomain systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 1366 (packagekitd)


Even when I reboot with systemd.log_level=debug there's no additional information about what triggers the automount. I have no idea what packagekitd is looking for (maybe an auditd watch rule could help) but anyway it seems like whatever is supposed to filter is not in fact filtering on Fedora 26.

why is this a gvfs bug when packagekitd is triggering the automount ?

(In reply to Matthias Clasen from comment #6)
> why is this a gvfs bug when packagekitd is triggering the automount ?

gnome-settings-daemon also is as well. I'm pretty sure they're not triggering it themselves, but simply looping over mounts offered by gvfs automounts them. See bug 781868 (which I'm not touching until this one is resolved, and even then, I've yet to see a reason for me to spend time looking into it).

There is already bug 781869 specifically for packagekit, but I think it's unlikely any of these things are doing anything differently all of a sudden now. More likely is the filtering described in comment 2 and 3 isn't working now for whatever reason.

packagekitd uses GVolumeMonitor because it is looking for instalation media, so it is probably GVfs fault, because we should not offer such mounts from GVfsUDisks2VolumeMonitor...

However, gnome-settings-deamon uses GUnixMounts directly, so it is not caused by GVfs, but there is probably the same problem with filtering as it is in GVfsUDisks2VolumeMonitor (the same for gvfsd-trash).

I will try to reproduce...

It is caused by mnt_table_is_fs_mounted call from g_unix_mounts_get, so the unwanted automounts may be triggered by all applications which use g_unix_mounts_get! See the documentation:
https://www.kernel.org/pub/linux/utils/util-linux/v2.29/libmount-docs/libmount-Table-of-filesystems.html#mnt-table-is-fs-mounted

This probably needs to be replaced by mnt_table_find_source as per the documentation, but I don't see why it is used here...

Mario?

*** Bug 781868 has been marked as a duplicate of this bug. ***

*** Bug 781869 has been marked as a duplicate of this bug. ***

(In reply to Ondrej Holy from comment #10)
> It is caused by mnt_table_is_fs_mounted call from g_unix_mounts_get, so the
> unwanted automounts may be triggered by all applications which use
> g_unix_mounts_get! See the documentation:
> https://www.kernel.org/pub/linux/utils/util-linux/v2.29/libmount-docs/
> libmount-Table-of-filesystems.html#mnt-table-is-fs-mounted
> 
> This probably needs to be replaced by mnt_table_find_source as per the
> documentation, but I don't see why it is used here...

At the time I wrote that I used it because I thought that was the way to check whether a fs was mounted, but it seems that I was wrong and should have probably used mnt_table_find_source() instead.

So, long way of saying that I don't see any reason why that function could not be replaced with mnt_table_find_source(), although from a quick look to the documentation it's not entirely clear to me how to do that.

I've been talking about with Karel Zak. I will propose a fix for it later today.

Thanks for taking care of this Ondrej, and for contacting Karel (he's been very helpful to me in the past), I'll be happy to review that once it's ready.

Created attachment 351184 [details] [review]
gunixmounts: Speed up mtab processing with libmount

libmnt_context is useless. It contains cache which is useful for searching,
but it isn't used in our case. Let's use mnt_context_parse_mtab instead
directly and the mtab processing will be faster.

Created attachment 351185 [details] [review]
gunixmounts: Prevent unwanted automount requests

mnt_table_is_fs_mounted causes unwanted automount requests due to
canonicalization of source and target. It might be replaced by
mnt_table_find_source as per the documentation in order to prevent
the automounts, but it is redundant. All mtab entries should be already
mounted and thus mnt_table_is_fs_mounted result is always true (it
basically checks that the fs from mtab is in mtab). Let's remove
the check at all.

Chris, can you please verify that it fixes the unwanted automounts?

You can try the following scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=19409547

The patches seem good from my point of view.

The original version with mnt_table_is_fs_mounted() makes no sense. It tries to verify that 'fs' from the 'table' is included in the 'table' -- the result is always true :) 

The function is designed for verify that 'fs' from another table (usually fstab) is included in the 'table' (=mtab).

Anyway, you don't have to try verify anything if you read mountpoints from kernel. The mtab is almost everywhere symlink to /proc/mount. 

For very small subset of the installed systems (slackware?) where mtab is a regualar file it makes a little bit sense, but IMHO it's still unnecessary paranoia.

Looks good to me too, but maybe it's sane to wait for Chris to test it if possible before committing. Also, sorry for introducing the issue in the first place.

(In reply to Ondrej Holy from comment #19)
> You can try the following scratch build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=19409547

Updated to this, and now the problem does not happen with /boot/efi anymore.

There is a residual process that is still automounting /boot however,

May 05 11:24:53 f26h.localdomain systemd[1]: boot.automount: Got automount request for /boot, triggered by 2240 (fwupd)
 
Let me know if I should file a separate bug to track that.

Thanks all for your comments!

fwupd doesn't use GUnixMounts, neither GVolumeMonitor, so it is not relevant to this bug. It is a daemon for updating firmware, so I suppose it needs access in /boot dir for its purpose. However, you can try to fill a bug there:
https://github.com/hughsie/fwupd/issues

Review of attachment 351184 [details] [review]:

Thanks Chris for testing this, I think this is good to commit now then

Review of attachment 351185 [details] [review]:

And this one too, of course...

Attachment 351184 [details] pushed as 53ed180 - gunixmounts: Speed up mtab processing with libmount
Attachment 351185 [details] pushed as 83c1b88 - gunixmounts: Prevent unwanted automount requests

I've pushed attachment 351185 [details] [review] into stable branches as well...

Created attachment 360754 [details] [review]
gunixmounts: Fix mount points generation

Commit 53ed180 improved mtab processing, however, also introduced bug
in code obtaining mount points. mtab was used by mistake also for
g_unix_mount_points_get implementation, which is obviously wrong and
fstab has to be used instead...

Review of attachment 360754 [details] [review]:

Looks good to me.

Is there any possibility of building some regression tests for the GIO mount handling? It seems like there are a lot of interactions which we want to test always continue to work.

Attachment 360754 [details] pushed as f6fa90f - gunixmounts: Fix mount points generation

Pushed to stable as well.

It would be nice to have some tests for it, but it won't be possible without root permission I afraid, so not suitable for some automated testing...

(In reply to Ondrej Holy from comment #31)
> It would be nice to have some tests for it, but it won't be possible without
> root permission I afraid, so not suitable for some automated testing...

I would be happy for some tests to be added to GLib which are skipped unless running as root. They wouldn’t get run automatically when building, but maybe we could hook them up in a CI system; and they could certainly get run manually by developers occasionally. The value comes from the tests encoding the behaviour which we expect to be preserved by GLib.

*** Bug 788290 has been marked as a duplicate of this bug. ***

*** Bug 786570 has been marked as a duplicate of this bug. ***