Gnome Places contains filesystems mounted via bind

[Sebastian Geiger]

Binary package hint: nautilus

What happens:
1. mount a folder a to point b with the -bind option in /etc/fstab, for example:
     /media/data /home/username/MyDocuments none bind,user=username,group=username 0 0
2. reboot and then open nautilus
3. nautilus will show the new mount point in the places sidebar but it will give you an error if you click on the mount point:
    Unable to mount MyDocuments
    mount: according to mtab, /media/data is already mounted on /home/username/MyDocuments
mount failed

What should happen:
1. nautilus should not show these binded folders since they are well accessible through the filesystem
2. if the mounted folder (e.g. /mount/data) is a block device then it will appear in the places sidebar anyway and thus it is not necessary to show the mount point again
3. if the mounted folder is a normal folder from an existing file system then its accessible both from the original location and the newly binded location, thus the is no need to show it in places again
4. this is quite annoying

Additional Information:
This bug persists in Lucid

ProblemType: Bug
Architecture: amd64
Date: Thu Oct 15 12:04:11 2009
DistroRelease: Ubuntu 10.04
Package: nautilus 2.30

[Scott James Remnant (Canonical) (canonical-scott)]

Since they're already mounted, this can't be a mountall bug - it's a nautilus bug for showing them and getting itself confused

[Sebastien Bacher (seb128)]

Thank you for your bug report, could you get a gvfs-mount -li log?

[Sebastian Geiger (lanoxx)]

See my Log attached. I only removed one ftp mount point which containted
  a username. The rest is as is.

Sebastien Bacher wrote:
> Thank you for your bug report, could you get a gvfs-mount -li log?
>
> ** Changed in: nautilus (Ubuntu)
> Importance: Undecided => Low
>
> ** Changed in: nautilus (Ubuntu)
> Status: New => Incomplete
>

[Sebastian Geiger (lanoxx)]

Hi,

just wondering if you need further information as the bug is still marked as incomplete?

[Sebastian Geiger (lanoxx)]

Now already three month have passed and this bug is still marked as incomplete. Am I the only one that has this bug? Or can nobody reproduce it? I am still having this bug on my pc, even with all current updates.

[Sebastian Geiger (lanoxx)]

 the mounting seems to be done in libnautilus-private/nautilus-file-operations.c, in the function nautilus_file_operations_mount_volume_full
Maybe it would help to check if the volume is actually mountable or whether it is mounted with the bind option. I have no experience with compiling nautilus but maybe someone can take a look at this function? Also g_volume_can_mount might be useful? Just a thought.

[Sebastian Geiger (lanoxx)]

I have marked the bug as confirmed since I was able to reproduce it on three different computers.

[Sebastian Geiger (lanoxx)]

Today I have had some time to investigate this problem. It seems the bug originates from glib and is not actually a bug in nautilus, the reason is that mount points that are mounted with the bind option dont the a GMount mount point assigned from glib.

I have explained the behaviour here: https://bugzilla.gnome.org/show_bug.cgi?id=625552

If g_volume_get_mount() would return a GMount pointer for the mount point then nautilus would display the file as mounted and not try to mount it again.
Unfortunately there seems to be no way to check the mount options of a given mount point in glib.

[Sebastian Geiger (lanoxx)]

i have just linked the upstream bug and changed the package to glib2.0 as this is not directly a nautilus bug (also nautilus might need to be changed too, once this is fixed upstream).

[Dominique Brazziel (dbrazziel)]

Hello all. Thank you for working on this bug, I have been working on it for the past few days and this thread clears things up quite a bit. Since reading this, I took a look at some gio code and was thinking one of the functions in 'giounixmounts.c' might be of some assistance in determining if the volume is already mounted? For instance, in my case I have an fstab entry for '/dev/sdX'
mounted at mount point '/av', then later a bind mount for 'device' /av at mount point '/export/av' (for NFS sharing with other machines on the LAN).

A list of all mounted volumes can be gotten via 'g_unix_mounts_get () ' in 'giounixmounts.c', which has logic to deal with bind mounts. Perhaps check somewhere to insure that the places menu is not populated with this entry that is about to be mounted if GUnixMountPoint (/av) is equal to a previously mounted GUnixMountEntry (/av).

[Dominique Brazziel (dbrazziel)]

Er, check that,. The check might go in 'g_volume_monitor_get_volumes()', 'g_volume_can_mount()', 'g_volume_get_mount()', and maybe' g_volume_get_drive()' functions.

[Sebastian Geiger (lanoxx)]

I can not find a file called giounixmounts.c where is this located? can you provide a link or path in the git repository?

[Dominique Brazziel (dbrazziel)]

Ack, my fault. In the glib source, subdirectory 'gio', see 'gunixmounts.c' and company.

[Michael Weimann (m982)]

Since the update to Ubuntu 12.10 beta this bug affects me. Under 12.04 the behavior was as expected: bind mounted directories were not shown as devices.

[Sebastian Geiger (lanoxx)]

This surprises me, because I am under 12.04 and do see this bug, its actually present since several years.

The problem lies in the code of glib. Nautilus actually has some code in place to differentiate between bind mounted mount points and other mount points. But glib (gio) is not properly handling this case, so the check in nautilus is never reached.

[Otus (jan-varho)]

Like Michael Weimann, I only started seeing this under 12.10. Ubuntu 12.04 was fine, although I copied my fstab over. Maybe the bug used to be quite specific, but now applies more generally.

One difference I see from the OP is that my mounts are all root:
/media/data/folder /home/username/folder bind bind 0 0

[Sebastian Geiger (lanoxx)]

The upstream bug has now a working patch for the problem. If it cannot be backported then it should probably arrive in Gnome 3.8

--- a/gio/gunixmounts.c
+++ b/gio/gunixmounts.c

+ /* We ignore bind fstab entries, as we ignore bind mounts anyway */
+ if (hasmntopt (mntent, "bind"))
+ continue;
+

Maybe some of the Ubuntu developers can look at it, and commend if this patch is eligible for a Stable Release Update?

[Sebastien Bacher (seb128)]

@Otus: raring is tracking the current unstable glib so that fix will land with the next release

[Sebastian Geiger (lanoxx)]

It would be quite nice to get this fix pack ported to quantal and precise. Given its only a two liner I assume there wont be much if any side effects to this patch.

[Sebastien Bacher (seb128)]

> It would be quite nice to get this fix pack ported to quantal and precise. Given its only a two liner I assume there wont be much if any side effects to this patch.

that's why a "precise" line was added to the bug table, I'm unsure it's worth backporting on nonLTS (e.g quantal) though, that bug has 0 duplicate and 3 affected people, it's pretty much a corner case impacting very few people

[Sebastian Geiger (lanoxx)]

Correct me if I am wrong, but I am assuming that the effort does not increase if the fix is backported to two lines instead of one? This is probably a mostly automatic procedure, or not?

And it could after all make a few people happy :)

[Launchpad Janitor (janitor)]

This bug was fixed in the package glib2.0 - 2.35.4-0ubuntu5

---------------
glib2.0 (2.35.4-0ubuntu5) raring; urgency=low

  * debian/patches/git_fix_gvariant_tuple_checking.patch:
    - should fix a dconf-service segfault issue (lp: #1105102)
 -- Sebastien Bacher <email address hidden> Fri, 25 Jan 2013 18:08:29 +0100

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release