I'm seeing this problem too.

I haven't quite figured out what triggers this exactly, but I have two suspicions, because it happens especially when I try to "unmounting" one of the two bookmarks I have on a server of mine. It keeps reappearing, needing to be unmounted twice.

So I'm wondering if it is:
- Something to do with the state of the sidebar's scrollbar (my initial thought)...

- Something to do with the fact that there are two bookmarks on different locations of the same server. Are you in the same situation as me?

Ah, I noticed something interesting just now. Let's say I have my local ~/Downloads folder (the xdg downloads dir) in the sidebar, and a bookmark to a sftp remote (named "foo").

If you click foo, it mounts the remote (so it appears at the bottom).

If you click to go to another local folder (such as ~/Downloads) and then try to directly click the unmount icon for "foo", you'll never be able to unmount it as it will be remounted everytime. However, if you click foo to enter that directory before clicking the unmount icon, unmounting will work properly.

Seems like something is not handling click targets correctly here.

(In reply to comment #2)
> Seems like something is not handling click targets correctly here.

It remind me of bug 699183. Does the patch commited for that bug fix this one?

This applies to all mounted backends, I think. I've been trying to fix some crash on exit scenarios in the gvfs-mtp backend, and I see that Nautilus will often issue a query_info request after the unmount. This originally led to the crash, but now it leads to either a successful remount or a Nautilus error. I haven't found a way to make Nautilus silently accept that the operation failed either.

I'm getting this here, too.

It feels like this is caused by the fact that bookmarks are duplicated in network mounts, if matching.

Unmounting is only possible under Network, but nautilus re-selects the bookmark after unmounting the entry and goes into a race - sometimes it will remount, sometimes error out.

A simple fix from user-experience PoV would be to not display a separate entry under Networks, but just display the icon next to the bookmark entry, so it would behave more like other mounts.

I did some digging and I can confirm it's related to unmounting from the button in the sidebar. If you unmount some other way (such as right clicking on the device in the location bar and choosing unmount) then no inappropriate operations are triggered on the device.

I believe this is the relevant backtrace:

+ Trace 232857

It occurs twice for two file locations:

(gdb) p *((*file)->details)
$10 = {directory = 0x143b5c0, name = 0x18e2d04 "usb:005,002 (mtp)", type = G_FILE_TYPE_DIRECTORY, 
  display_name = 0x1544fe4 "Unnamed Device", 

(gdb) p *((*file)->details)
$11 = {directory = 0x143b5c0, name = 0x18a9d74 "Internal storage", type = G_FILE_TYPE_DIRECTORY, 
  display_name = 0x18a9d74 "Internal storage", 

I believe the first location is fine, as that gets handled inside nautilus but the second one is dispatched to the backend, leading to the errors.

Obviously, we should not be seeing #11 bookmarks_row_activated_cb -> #10 open_selected_bookmark occurring when that unmount button is clicked.

Further note - this only applies to Nautilus 3.8 where there is still the custom sidebar. In 3.9/10, we've got the GtkPlacesSidebar which may not may not be buggy.

With respect to 3.8, I notice:

static void
bookmarks_row_activated_cb (GtkWidget *widget,
                            GtkTreePath *path,
                            GtkTreeViewColumn *column,
                            NautilusPlacesSidebar *sidebar)
{
        GtkTreeIter iter;
        GtkTreePath *clicked_path = NULL;
        GtkTreeModel *model = gtk_tree_view_get_model (GTK_TREE_VIEW (widget));

        if (!gtk_tree_model_get_iter (model, &iter, path)) {
                return;
        }

        if (!clicked_eject_button (sidebar, &clicked_path)) {
                open_selected_bookmark (sidebar, model, &iter, 0);
        } else {
                gtk_tree_path_free (clicked_path);
        }
}

So it does attempt to avoid this problem, but that clicked_eject_button() test clearly isn't working.

Will update with more details on that.

*doh*.

Now it all makes sense. The fix for the sidebar activation was made *after* 3.8.2 was released and there's never been a 3.8.3. So that's what's going on here. So I suspect everything is actually fine if your build is new enough and 3.9/10 should be fine too.

Yes, in 3.8 the workaround of right-clicking to unmount does the trick, and the actual fix never made it into a 3.8.3 release.

3.10 is not affected by this bug. I'm tempted to say it could be marked resolved fixed then...

Marking as resolved as per comment 9.

Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME (3.10 or later).