I confirm this for Nautilus 3.18.2 on Fedora 23.

It happens for me with sftp:// servers. smb:// servers work fine.

My workaround:

1. After getting "The folder is empty" message, click each button in the "breadcrumbs bar" starting at the leftmost button, which represents the root of the remote server.

2. If you get the error "Oops! Something went wrong. Location is already mounted," click F5 to refresh.

Can you try one thing for me?

Bookmark a root location of your server.
Click the bookmark.
Wait til open.
Unmount on the sideber.
Click the bookmark again.

Does it crash?

Thanks

That scenario worked fine. It did not crash.

Oh, and I take back what I said about smb servers. It turns out smb servers exhibit the similar behavior to sftp servers.

smb://WORKGROUP;user@example.com/sharename/ 

works fine. I can unmount and remount the bookmark. 

But if I add additional path, like:

smb://WORKGROUP;user@example.com/sharename/subdir1/

this gives the "The folder is empty" message if I try to mount the bookmark a 2nd time.

hm I see, that scenario should crash if my understanding is correct about the issue. Basicallly I'm pretty sure is a ref counting issue.

Explanation (mostly as a personal note):

Currently, file attributes are invalidate when changing location
if the location is either a regular file, so it needs to go
to the parents to search for a directory, or when the file is
a mount and it's not mounted.
However, once the file info is retrieved is cached and it needs to be 
invalidated if it wants to check if it's mounted or not.

When changing locations, NautilusWindowSlot is the responsible of taking
care of knowing if the location needs mounting.
How does it?
It simply tries to get the general info from the file, and if the file
is not mounted an error will be reported, then window slot will mount it
and afterwards will try to get again the general info of the file, and
this time if everything went well will succeed and the location will
finally change.

However, nautilus cache the info of the files, therefore if nothing
invalidates that info, when requested it returns the cached info.

The problem with this is that, as an example, if try to open an
unmounted location for first time the info is not cached and everything goes
well, however if there is a ref count issue and the file is unmounted, since
nautilus splits directories and file management, the directory gets
correctly eliminated following the unmounting (since it's the parent),
however the associated file is not finalized due to a leak, making
the info of the file be "valid", so next time nautilus tries to request
its info to see if it is mounted it will say it is, because the info
is cached.

To workaround it the info can be invalidated before changing locations, and
actually window slot already does that for some of its operations (which I
don't agree since it's a "workaround all" thing), however I prefer to fix
the real issue, the ref counting.

-> 3.18, track it to close it when done. I'm on it.

Created attachment 317233 [details] [review]
window-slot: invalidate file attributes on reload

Files attributes in nautilus are cached, and sometimes having a cached
value its problematic for special cases like mounting due to how window
slot mounts locations, which relies in the file not having the mount
information ready, which is not true when the file doesn't get
finalized and doesn't get acknowledge by the volume monitor when its
root gets unmounted.

To avoid that, invalidate all file attributes when changing locations.

A better solution for this specific case would be to make the root
volume monitor to acknowledge all its children when unmounted, and keep
it alive as long as there are children.

But this fix is anyway needed since previous 3.18 is how it was done and
seems it's a needed for now "workaround all" issues with cached values.

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

Attachment 317233 [details] pushed as 3bca716 - window-slot: invalidate file attributes on reload