Adding the following rules to /etc/udev/rules.d/86-no-automount.rules fixes the problem locally (on Ubuntu Precise):

ENV{UDISKS_PRESENTATION_HIDE}="1"
KERNEL=="sd*|hd*|sr*|mmcblk*|mspblk*", ENV{UDISKS_PRESENTATION_HIDE}="0"

Any chance we can add these rules into the default configuration? There seems to be no reason for gvfs-gdu-volume-monitor to automount loop devices...

Tested some more locally and the above fix solves half the problem. The other half of the problem is that the gvfs trash daemon creates a .Trash directory inside mount points.

This problem can be worked around entirely using the following workaround:
  sudo killall -STOP gvfs-gdu-volume-monitor gvfsd-trash

We use the above workaround in the Chrome OS build system to ensure that gvfs doesn't mess with our loop devices. There must be a better way, though...

(In reply to comment #0)
> You can also work around the bug by sleeping for a few seconds prior to unmounting the loop device.

Yes, that's intentional and sleeping is my preferred solution. GVfs volume monitors are sniffing fresh mounts to get an idea of their contents.

>   1) gvfs-gdu-volume-monitor should not be touching loop devices at all -- they
> are not removable media so they should not be automounted.

Automount policy is a separate thing from sniffing.

>   2) It should be possible to disable the automount behavior of
> gvfs-gdu-volume-monitor.

With udisks2 volume monitor, you can mount with the "x-gvfs-hide" option to prevent GVfs from showing the mount, possibly disabling sniffing altogether. Please see http://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt

The gdu volume monitor is practically unmaintained and superseded by the udisks2 volume monitor.

(In reply to comment #1)
> Adding the following rules to /etc/udev/rules.d/86-no-automount.rules fixes the
> problem locally (on Ubuntu Precise):
> 
> ENV{UDISKS_PRESENTATION_HIDE}="1"
> KERNEL=="sd*|hd*|sr*|mmcblk*|mspblk*", ENV{UDISKS_PRESENTATION_HIDE}="0"
> 
> Any chance we can add these rules into the default configuration? There seems
> to be no reason for gvfs-gdu-volume-monitor to automount loop devices...

There has been number of changes recently in the udisks2 monitor wrt automounting, resulting in slight policy change. Suggesting to try that first.

(In reply to comment #2)
> This problem can be worked around entirely using the following workaround:
>   sudo killall -STOP gvfs-gdu-volume-monitor gvfsd-trash

Please note that disabling part of GVfs functionality would possibly make you even more problems.

The script in comment 0 has this line

 TMP_MOUNT=$(mktemp -d --suffix=-gvfs-test)

which produces a mount point in /tmp which in 3.4 and onwards (that is, using gvfs-udisks2-volume-monitor) should be completely ignored as we only show stuff mounted in /media, $HOME and /run/media/$USER (see the what-is-shown.txt doc).

I'm pretty sure that gvfs-gdu-volume-monitor does something similar, that is, it only shows mounts in /media and $HOME (it predates /run/media/$USER). Maybe a Ubuntu vendor patch is changing this? I don't know.

Another thing is that if you prefix any directory in the mount point with a "." it should also be ignored by the desktop bits (same way we don't show files/dirs starting with "." in the file manager). At least this works with gvfs-udisks2-volume-monitor but I'm also pretty use it works with gvfs-gdu-volume-monitor.

Btw, the race you are describing is really unavoidable unless you take extra care to ensure that the desktop bits ignore the mount ... at least with the newer stuff (e.g. gvfs-udisks2-volume-monitor) it's now well documented what the behavior is (the what-is-shown.txt document), if not, please file bugs!

Hope this helps.

(In reply to comment #1)
> Any chance we can add these rules into the default configuration? There seems
> to be no reason for gvfs-gdu-volume-monitor to automount loop devices...

I'm very sure we're not automounting loop devices even in the gdu volume monitor (just checked the code, see [1]). If we were automounting them, they would be mounted in /media but all the information you provided thus far been about you mounting them yourself and the mount points being in /tmp.

Maybe you meant that the desktop bits shouldn't be looking at files inside a mount? My response to that is the last paragraph in comment 4 e.g. either

 a) you mount the device in a place so the desktop ignores it; or

 b) you need to cope with other processes holding files open for a short while

It would probably be helpful if you provided some more detailed information ... such as the output of 'gvfs-mount -oi' running in the session... that way it's a lot easier to figure out what the problem actually is. Thanks!

[1] : http://git.gnome.org/browse/gvfs/tree/monitor/gdu/ggduvolume.c?h=gnome-3-2#n366

Updating summary to more accurately reflect what I think is actually going on (as per comment 5).

Created attachment 216417 [details]
/tmp mounts on GNOME 3.4

Btw, just tried this on Fedora 17 (which has gvfs-udisks2-volume-monitor) and it works as expected: 1. loop device is not automounted; 2. when mounted in /tmp, the desktop ignores the mount point; 3. when mounted via the desktop, the mount point does appear. See attached.

(In reply to comment #5)
>  a) you mount the device in a place so the desktop ignores it; or

What directory can I mount the device in that will cause the desktop to ignore it? Prefacing the mount point with '.' doesn't work -- gvfs-gdu-volume-monitor still looks at files inside the mount point. Prefacing the image file with '.' doesn't work either...

Here is the output for gvfs-mount -oi and my script, interleaved:
  http://pastebin.com/mWwrrj1J

Here is another case where (in a real build script) I am unable to umount /tmp/esp.GO0kc5 inside a chroot. The attached paste shows the gnome-mount output: http://pastebin.com/XdL9Zq3z

Also similarly, I have trouble unmounting bind points created with 'mount --bind' when gvfs is running, even if there is a long delay in between the mount and unmount.

Stopping the gvfs-gdu-volume-monitor and gvfsd-trash daemons works around all of the above problems.

It sounds like new versions of gvfsd are significantly better. It would be great if we could get these fixes backported to Ubuntu Precise...

(In reply to comment #8)
> (In reply to comment #5)
> >  a) you mount the device in a place so the desktop ignores it; or
> 
> What directory can I mount the device in that will cause the desktop to ignore
> it? Prefacing the mount point with '.' doesn't work -- gvfs-gdu-volume-monitor
> still looks at files inside the mount point. Prefacing the image file with '.'
> doesn't work either...

The gdu code uses g_unix_mount_guess_should_display(), see

 http://git.gnome.org/browse/gvfs/tree/monitor/gdu/ggduvolumemonitor.c?h=gnome-3-2#n714

and this function is here (haven't changed much since its inception)

 http://git.gnome.org/browse/glib/tree/gio/gunixmounts.c#n2062

which, as you can see, basically only returns TRUE if the conditions I mentioned in comment 4 are TRUE (e.g. mount in $HOME, /media and directory not starting with a "."). So that makes me a little surprised to see that we add a mount in /tmp

 Mount(0): 10 MB Filesystem -> file:///tmp/tmp.4qsCSEuhS8-gvfs-test

Anyway, all this code is kinda horribly complicated so it's definitely not impossible there are bugs...

> Here is the output for gvfs-mount -oi and my script, interleaved:
>   http://pastebin.com/mWwrrj1J
> 
> Here is another case where (in a real build script) I am unable to umount
> /tmp/esp.GO0kc5 inside a chroot. The attached paste shows the gnome-mount
> output: http://pastebin.com/XdL9Zq3z
> 
> Also similarly, I have trouble unmounting bind points created with 'mount
> --bind' when gvfs is running, even if there is a long delay in between the
> mount and unmount.
> 
> Stopping the gvfs-gdu-volume-monitor and gvfsd-trash daemons works around all
> of the above problems.
> 
> It sounds like new versions of gvfsd are significantly better. It would be
> great if we could get these fixes backported to Ubuntu Precise...

Created attachment 216431 [details]
Test script on F16

This is the test script on F16 (from a F16 live CD)... it works as expected.

Looks like your problem is specific to Ubuntu then... can you or an Ubuntu developer please check what vendor patches are used?

(In reply to comment #10)
> Created an attachment (id=216431) [details]
> Test script on F16
> 
> This is the test script on F16 (from a F16 live CD)... it works as expected.
> 
> Looks like your problem is specific to Ubuntu then... can you or an Ubuntu
> developer please check what vendor patches are used?

(Just a note: F16 is using the same old gvfs-gdu-volume-monitor process as you are on Ubuntu. It's F17 that is using the new udisks2-based stuff.)

I guess we can close this as NOTGNOME for now since a) GVfs is designed to ignore mounts outside /media and $HOME; and b) GVfs actually doesn't interfere at least not on F16 (which has zero vendor-patches in this area).

(FWIW, I'm still interested in knowing what vendor patches (not to mention package versions, just saying "Ubuntu Precise" is just not good enough) are being used because I agree it's the effects of the bug is really bad - it's just not supposed to happen and if it is, I'd like to tell whoever responsible for shipping those patches to not do that in the future. Thanks.)

For the record, I get the same on gvfs 1.13.1 and udisks2. I did a first analysis in https://bugs.launchpad.net/gvfs/+bug/1010141/comments/10 . TL;DR is that it's got nothing to do with automount, but apparently it's a race of gvfsd-trash accessing a new mount for a short time, and an immediate umount after the mount. I'm investigating this more closely now, will update the downstream bug report, and follow up with a final analysis here (reopening the bug if appropriate).

Still doesnt explain why you see

Mount added: '10 MB Filesystem'
  Mount(0): 10 MB Filesystem -> file:///tmp/tmp.4qsCSEuhS8-gvfs-test

in http://pastebin.com/mWwrrj1J and why I don't see this in F16. Martin: do you see this with the distro version the reporter is using? (eg not using udisks2)

Could be there are two bugs... one in gvfsd-trash and one elsewhere