gvfs fuse mount is not functional after logout and subsequent login

[Nikita Frolov]

Binary package hint: gvfs

GVFS-backed mounts are working perfectly on fresh OS boot. After logout and following login every attempt to access $HOME/.gvfs (i.e. with ls or df) results in 'Transport endpoint is not connected' error message. At the same time $HOME/.gvfs is present in /etc/mtab. Also GVFS-mounts are accessible through FUSE when /usr/lib/gvfs/gvfs-fuse-daemon is called with some other directory as argument.

Branch of Ubuntu involved is hardy (with all current updates installed), version of gvfs, gvfs-backends, gvfs-fuse and libgvfscommon0 packages is 0.2.2svn20080403-0ubuntu1.

TESTCASE:

- log into GNOME
- browse a network location using nautilus
- verify that the location is fuse mounted under .gvfs
- close your session
- switch to a vt and look to .gvfs or log again and do that, you should get an error saying that .gvfs is not connected
- install the update
- try those again, now .gvfs is correctly unmounted on logout, and on next login it's still usuable

[Nikita Frolov (mkmks-deactivatedaccount)]

I noticed that manual unmounting of $HOME/.gvfs before logout resolves the issue. Probably it should be automated somehow?

[fnf (vanhtu1987)]

Confirmed, I just filed a bug about pulseaudio not working after logging in again. Perhaps a console-kit issue?.

I have long dropped the use of 'startx' but use straight GDM. Although many problems arose with it, namely SCIM the environment variables not being exported unless you fiddle with the files in /etc/X11/Xsession.d/.

[Sébastien Corriveau (sebcor-deactivatedaccount)]

Changed to "Confirmed" since I'm experiencing the exact same behavior,

[Tuomas Aavikko (taavikko)]

I too suffer from same issue, tried using Nick Frolov's advice on manually unmounting the .gvfs folder.
The problem is only half solved...
 ls -la |grep .gvfs
dr-x------ 2 user user 0 2008-04-19 18:35 .gvfs

Notice the permissions on folder?
on my 64bit systemm the folder has also write permission.

At the current state, nautilus seems sluggish and it crashes from time to time?

[Øyvind Stegard (oyvindstegard)]

Seeing this as well (clean Hardy install from release-candidate image, all updates as of Apr 22 2008 applied). The ~/.gvfs mountpoint becomes unusable after logout/login, with "transport endpoint not connected" error. Observed with both sftp:// and smb://.

[Øyvind Stegard (oyvindstegard)]

Confirming that a work-around is to manually unmount the ~/.gvfs using:
$ fusermount -u ~/.gvfs

Then close/unmount all opened remote locations in Nautilus and log out and back in, again. This restores the .gvfs-functionality for me.

[Øyvind Stegard (oyvindstegard)]

I'd like to add that the .gvfs mount point functionality sometimes (or rather often) just breaks without reason (with transpoint endpoint not connected error), even though no logout/login has been done. So it's a more generic problem.

[Sebastien Bacher (seb128)]

> the .gvfs mount point functionality sometimes (or rather often) just breaks without reason

the issue seems to be a server crash, are you using the hardy-proposed update which has a fix for some issues?

[Øyvind Stegard (oyvindstegard)]

From the syslog when gvfs-fuse-daemon died:

Apr 27 15:05:31 blackelf kernel: [153199.221146] gvfs-fuse-daemo[31253]: segfault at 72656e65 eip b7ef5e76 esp b49b90a0 error 4

This happened when accessing a mount through the smb:// protocol under ~/.gvfs using Firefox.

More debugging info can be provided on demand or perhaps a new gvfs bug report should be opened regarding the segfault in gvfs-fuse-daemon.

[Øyvind Stegard (oyvindstegard)]

Here's the very reproducible crash with gvfs-fuse-daemon debug output enabled:

unique: 51, opcode: GETATTR (3), nodeid: 5, insize: 56
unique: 52, opcode: RELEASE (18), nodeid: 5, insize: 64
RELEASE[134851312] flags: 0x8000
unique: 53, opcode: LOOKUP (1), nodeid: 3, insize: 48
LOOKUP /oyvind-home på gandalf/.bashrc

GThread-ERROR **: file /build/buildd/glib2.0-2.16.3/gthread/gthread-posix.c: line 171 (g_mutex_free_posix_impl): error 'Device or resource busy' during 'pthread_mutex_destroy ((pthread_mutex_t *) mutex)'
aborting...
Aborted

Daemon was started manually as regular user by issuing:
$ /usr/lib/gvfs/gvfs-fuse-daemon -d ~/.gvfs

The mount works fine from within Nautilus itself. Again, triggered by listing the root directory of the mount using Firefox open file dialog through ~/.gvfs. It can also by triggered by the open file dialog of any other Gnome app, it seems. I crashed it using gedit as well (I know gedit can open smb:// natively, but that's beside the point).

Note that doing:
$ ls ~/.gvfs/MOUNTNAME/

works as expected, and the daemon does not crash.

[Øyvind Stegard (oyvindstegard)]

I have hardy-proposed enabled, but haven't received the updated gvfs package yet (still at verison 0.2.3-0ubuntu4 from main/release). I'm using a Norwegian mirror, so maybe it hasn't propagated there, yet ? I'll just install the updated package manually and report back.

[Øyvind Stegard (oyvindstegard)]

I am unable to reproduce the crash using the latest gvfs update from hardy-proposed ((0.2.3-0ubuntu5). Opening files under ~/.gvfs with Firefox works fine and no crash occurs in gvfs-fuse-daemon.

So this:
  * debian/patches/94_from_svn_fix_referencing_issues.patch:
    - change from SVN, fix referencing issues leading to gvfsfuse crashes
      (lp: #211205)

seems to have fixed it, thanks :).

Now I don't have to go down the painful "mount -t cifs ..."-road ;).

[Øyvind Stegard (oyvindstegard)]

However, the latest update doesn't fix the logout/login problem. So this bug cannot be closed as a result. I guess ~/.gvfs isn't properly unmounted on logout, so gvfs-fuse-daemon refuses to start on subsequent login. Sorry for bringing in the unrelated problem of daemon segfault into this bug report :/.

[Øyvind Stegard (oyvindstegard)]

I worked around this bug by adding:

# Quick and dirty hack to unmount ~/.gvfs directory on logout.
if test -d "$HOME/.gvfs" ; then
  /bin/fusermount -zu "$HOME/.gvfs" 1>/dev/null 2>&1 || true
fi

to the `/etc/gdm/PostSession/Default' script.

[Sebastien Bacher (seb128)]

right, you commented on a bug which is different from the one you were having, you should better open a new bug when the description doesn't match exactly yours, that makes easier to track issues

[Øyvind Stegard (oyvindstegard)]

Yep, sorry for the confusion, although both bugs bit me :).

[Jeremy Cantrell (jmcantrell)]

i am seeing the same behavior... "transport endpoint is not connected". is there anything that i can disable to get this to go away? i don't use windows shares.

i ended up creating a shell script called "gnome-session" in my bin folder that unmounts the folder first, then runs the real gnome-session. my xinitrc runs this wrapper script instead, which seems to fix this. the advantage being that it works with any display manager and with nomachine.

[Endolith (endolith)]

I am not getting the "transport endpoint" error, but ~/.gvfs locations are not working after logout. I created an sftp bookmark with Connect to Server, and when I link to it, the link is actually to ~/.gvfs as expected, but after reboot the ~/.gvfs folder has disappeared, and doesn't even reappear if I open the bookmark and navigate the files.

[ma2412ma (ma2412ma)]

I'm also experiencing this bug. I'd like to add the output of ls -la in my home, which seems strange to me:
d????????? ? ? ? ? ? .gvfs

Question 2: Suppose gvfs is working, wouldn't it be a good idea to make this more obvious to the users and not hide it somewhere as a hidden folder? On Mac OS X, they seem to use something with a similar results, everything gets mounted to /Volumes and is visibly accessible there.

[Sebastien Bacher (seb128)]

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=531516

[Hairy Hardon (glideraerobatics)]

It seems there are 2 different bugs being mentioned here.
I'm only experiencing what ma2412ma is (on Ubuntu 8.04), the frequent segfaulting of gvfs-fuse-daemon with ls -la returning "d????????? ? ? ? ? ? .gvfs" as output.
It happens when I'm editing files with gedit and browsing with Gnome Commander over my samba shares. I wrote a quick workaround that restarts gvfs-fuse-daemon whenever it croaks:

#!/bin/bash
# This is a workaround for some bug causing gvfs-fuse-daemon to frequently segfault
# and leave the ~/.gvfs directory inaccessable.
# It periodically checks the status of the directory and if it's broken,
# then it forces an unmount of the directory and starts gvfs-fuse-daemon.
#
# Start this script as a background process from .profile

dir="$HOME/.gvfs"

# Allow only 1 daemon process per user.
for pid in `ps -o'pid' --no-heading -C $(basename $0)`
do
 if [ $pid -ne $$ ]; then
  echo "$(basename $0) already running"
  exit
 fi;
done

# Loop forever
while :
do
 if [ ! -d $dir ]; then
  echo "Restarting gvfs-fuse-daemon"
  /bin/fusermount -zu $dir
  /usr/lib/gvfs/gvfs-fuse-daemon $dir
 fi
 sleep 10
done

[Forest Bond (forest-bond)]

Craig, and other folks suffering from the segfault issue: that is a separate issue, and you should create a separate ticket to deal with it.

[Forest Bond (forest-bond)]

I, too, am seeing the bad mount state after logout/login. Another particularly high profile user has also seen it:

http://arstechnica.com/reviews/os/hardy-heron-review.ars/5

This seems like it might be a somewhat widespread issue, and a relatively simple work-around is available. Perhaps a SRU is justified?

[michael crane (crane-ukfsn)]

hi, is it ok for non developers to post here ?
I get this too.

mick@ubuntu:~$ sudo find / -name avast
find: /home/mick/.gvfs: Permission denied
/usr/bin/avast

mick@ubuntu:~$ find / -name avast
find: /home/mick/.gvfs: Transport endpoint is not connected
/usr/bin/avast

[Ross Peoples (deejross)]

ma2412ma:
"Suppose gvfs is working, wouldn't it be a good idea to make this more obvious to the users and not hide it somewhere as a hidden folder?"

I have asked the same question in multiple places without answer. To further the question, why isn't gvfs-fuse installed by default? When a user mounts a share, they expect it to be accessible by ALL their applications, not just the core Gnome ones. I know that gvfs is a userspace filesystem, so why not mount it somewhere obvious in the user's home folder. Something like this maybe: "/home/user/Volumes". How is a new user supposed to know to install gvfs-fuse, then look in a hidden folder by the name of .gvfs?

[Sebastien Bacher (seb128)]

> why isn't gvfs-fuse installed by default?

it is installed on hardy

[Gavin Hamill (gdh)]

It is installed by default (I was the one who proposed its inclusion!)

I too am bitten by gvfs-fuse-daemon segfaults, despite being on 0.2.3-0ubuntu5 from proposed-updates :( Is there an easy 'debug build' which could provide more info / full backtrace?

[Ross Peoples (deejross)]

In Hardy Beta, you had to manually install it. I was not aware they had included it by default in the official release, but I am very glad they did. The only other real complaint (besides stability) that I have with it is the location of the shares. I really think they should be somewhere more visible, contained in a folder with a more meaningful name (e.g. ~/Volumes).

Like everyone else, I am also experiencing this bug. However, I actually have all my important stuff mounted using the /etc/fstab file. People tell me it's archaic to mount SMB shares using fstab, but it's the only reliable way to mount shares. I know they are thinking about phasing out the fstab file, but they really need to get gvfs reliable and matured before they do. Thus far, aside from bugs like these, they have done surprisingly well with its integration.

[Sebastien Bacher (seb128)]

nobody is wanting to replace fstab, there is no only desktop users running linux

to get a stacktrace you can attach gdb to process and see if that's crashing, the issue there is that the mountpoint is not unmounter between session, if you get crashes that's a different issue

[thecure (keith-k)]

> the .gvfs mount point functionality sometimes (or rather often) just breaks without reason

>the issue seems to be a server crash, are you using the hardy-proposed update which has a fix for some issues?

The only computer I am having this problem on is a fresh install Hardy 64 bit (DellXPS410.) (The problem just started a few days ago.) Previously this computer was a Gutsy to hardy update with no problems. My laptops were fresh hardy installs but do not suffer from this problem. The hardy-proposed does not correct the frequent gvfs mount point failures for me. I'll try to reinstall and see if the problem reappears.

[ma2412ma (ma2412ma)]

Yes, it's installed by default now. However, please make the mount point more visible - I suggest not to mount it within the home directory, but for example in /Volumes. Would that create problems for a multi-user environment? In Mac OS X, that's exactly the central location where everything gets mounted.

[Sebastien Bacher (seb128)]

why do you think that it would be better to have the mountpoints displayed? those are listed as mounts and the .gvfs mounts should automatically be used in a transparent way when you use an application not handling the gvfs locations directly

[Ross Peoples (deejross)]

Try opening a file located on a gvfs mount using VLC or some other non-gnome application, and you'll see why. Even though the applications may use the Gnome file dialog, the dialog itself sometimes hides connected shares, depending on the application. VLC is one example of such an application. They only way to access media on a remote share is to connect to the share using the mount command.

Another use case for visible, and easy to find mount points: What if I need to access an something on a remote share via a command line application? The only way to get to those shares from the terminal is to find the mount points.

Also, I noticed something interesting...I don't even have a ~/.gvfs folder, even though I have gvfs-fuse installed and shares connected.

ma2412ma: Though it would be nice to have a /Volumes at the root of the filesystem, gvfs-fuse is a userspace file system, meaning that once you log out, those shares are disconnected. There would also be permissions issues, which is why it's best to have it in the user's home directory.

[Sebastien Bacher (seb128)]

what you describe seems to be a vlc issue, it should not claim supporting vfs uris if it doesn't

[Jeremy Cantrell (jmcantrell)]

I think that ~/.gvfs is an appropriate location for fuse mounts. If
you want them to be more visible, then do: ln -s .gvfs Volumes. To
have gvfs create a real directory called "Volumes" in the home folder
doesn't seem like the "right" thing to do. To have it mount them in
/Volumes is definitely not the right thing to do. It violates the
linux filesystem hierarchy standard, which, i hope, is still followed.
Linux is not OSX, thankfully. Also, being that it's a user-space tool,
it only belongs in the home folder.

On Mon, May 12, 2008 at 8:40 AM, Sebastien Bacher <email address hidden> wrote:
> what you describe seems to be a vlc issue, it should not claim
> supporting vfs uris if it doesn't
>
>
>
> --
> gvfs fuse mount is not functional after logout and subsequent login
> https://bugs.launchpad.net/bugs/212789
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
:wq

[Ross Peoples (deejross)]

VLC is a widely used application and even though this may be their problem, don't count on them to fix it because they still haven't fixed a simple gui bug reported 5 years ago. But I'm not singling out VLC here, there are other applications I have come across that have the same behavior when it comes to gnomevfs/gvfs. The Gnome dialog simply won't let you select the shares. You have to manually navigate to their mount points. This in itself is frustrating enough, but having to right-click, show hidden files, and find .gvfs in my home folder (which I personally don't have for some reason) every single time you want to open a file with a non-gnome application is just plain stupid. Not to mention that I would have never found it if I didn't know how gvfs works.

[Hairy Hardon (glideraerobatics)]

About the comments regarding the 'hidden' .gvfs directory etc., what's stopping you from creating a symlink called "My Nice Shares" or whatever that points to the .gvfs directory, then it will be visible?

[Ross Peoples (deejross)]

Ok, as mentioned, for NEW users or others who are not as computer literate, having to explain that their share is in a hidden using a seemly strange name is not user-friendly. It's supposed to be Linux for Human Beings. If I shared out my movies folder, and set it up on my girlfriend's laptop so that she could watch them with VLC, or mplayer, she would immediately ask me why she can't find any of the movies in VLC, but she can find them in the file browser (Nautilus).

I have given plenty of reason as to why it should default to being easy to find, so now I ask why everyone is so against it? If it helps users, why is it such a bad thing?

So to answer your question, sure, I could make a symlink.....I COULD....not my girlfriend, not my grandmother, not my father, etc. And these are the people Ubuntu is targeted to.

[Sebastien Bacher (seb128)]

could you describe exactly in what situations those mounts are not accessible, using in preference an application installed in the default installation?

openin something from nautilus should transparently call software which don't support vfs uris using the .gvfs directories, the fileselectors have those mounts in the sidebar and those should work transparently the same way, how do you access those shares if that's not by using nautilus or a fileselector widget?

don't get those comments wrongly, that's not a refuse to fix the issue but it's not clear than having an extra directory is the right way to deal with the issue, having those listed as normal mounts and available in nautilus, in the GNOME places, etc should be transparent for the users and they should not have to figure where are the mounts, if you face issues there might still some work to do though

[Jeremy Cantrell (jmcantrell)]

it's perfectly clear why it SHOULD be hidden, by default. If it were a
real directory (vs a symlink), how would those of us (myself included)
who want to hide the directory do so?

[ma2412ma (ma2412ma)]

Of course I can make a symlink, but as Ross Peoples correctly writes, Ubuntu is for human beings and not (just) for Linux nerds. That's why it should just work. I understand that /Volumes is not the right location, but then it should be ~/Volumes and not a hidden folder.

Concerning the question why we should need to access the folders in .gvfs directly:
1. Try to open an OpenOffice document on a samba share.
2. Try to compile a LaTeX document on a samba share with gedit and the LaTeX plugin.
3. Try to do anything with the shell with stuff on a samba share.

Replace samba share above with SSH, FTP, ...

[ma2412ma (ma2412ma)]

jmcantrell: Then Ubuntu should create a symlink to ~/.gvfs called ~/Volumes by default (since there are some default folders like ~/Documents anyway). If you're unhappy with that, just delete the symlink.

[Ross Peoples (deejross)]

ma2414ma said it better than I probably could. I even have problems opening files in gedit for editing using gvfs via FTP. It tries to load them, then just stops and leaves you with a blank window. Another directory in the home directory may not be the best way to do it, but neither is a hidden folder in the home directory. I think ma2414ma's suggestion about having a symlink to .gvfs by default would work pretty well. It would certainly make it easier to find, as well as make it possible for someone like jmcantrell to remove the symlink in case you want to hide the directory. Also, it sounds like something that could be easily implemented by the devs.

jmcantrell: I don't think it is obvious at all why it should be hidden. Out of curiosity, what is your reasoning for having the directory hidden? I'd like to get a different point of view on the subject.

[Jeremy Cantrell (jmcantrell)]

i would want it hidden if i either don't use it or don't care about it.

[Ross Peoples (deejross)]

So as long as you have the option to quickly get rid of it, you'd be happy? Using a symlink by default would be a great help to new users, while taking less than two seconds to delete if you didn't want it, which would be jmcantrell's case.

[Sebastien Bacher (seb128)]

those comments are not really constructive there, gedit has issues because it's still using gnome-vfs and claim supporting vfs uris so nautilus call it using those uris, the way to fix that is to switch gedit to use gvfs and not to display implementation details to the user. try opening a text file over ssh using emacs and the fuse mount will be used automatically for example, do you have other issues examples?

[Sebastien Bacher (seb128)]

the reason why it's not a standard directory is because implementation details should not be showed to the users, they don't care what a mount is and what is the mountpoint, those should simply listed as mounted locations and being easily accessible in the file manager, file selectors and other desktop locations where they are required

[Ross Peoples (deejross)]

I agree that it should just work without ever needing to know how, but because of examples like those already given by myself and ma2414ma, not all applications are using gvfs (and some, like VLC don't play nice with it) yet, and it could be quite some time (or never) before they do. Providing a visible location for the mount points provides a workaround for the problems that currently exists. But even if those problems all got addressed, you'd still need the mount points in order to use the terminal with connected shares. Though it has already been mentioned that Linux is not OS X (and I too am glad it's not), Apple is all about the user experience and obviously they felt that having a /Volumes folder was sensible.

[Jeremy Cantrell (jmcantrell)]

i completely agree with sebastien.

[Jeremy Cantrell (jmcantrell)]

i could go into a rant about capitalization and whitespace in system
paths, but i'll save that for another day. there is already a
directory for system level mountpoints. it's called /mnt. the ubuntu
equivalent to mac's /Volumes appears to be /media. i'm not exactly
clear on what the difference is, other than gnome/nautilus sees one
and not the other.

we've already established that mounting user-space volumes outside of
the home folder is a no-no. exposing the mount points as a visible
directory in the home directory does not exactly follow with the gnome
standard. it doesn't exactly fit with what I, personally, would want,
but if you were following gnome's lead, it would have the volumes
visible on the desktop (similar to other mounted volumes), which could
be turned on/off via gconf editor
(/apps/nautilus/desktop/volumes_visible). this whole business about
whether or not to create a symlink to ~/.gvfs seems pretty pointless.
If you want the link, create it.. if not, don't.

also, i don't mean to be a party pooper, but does any of this
discussion have anything to do with the big hairy wart of a bug that
this thread is supposed to be about. if you ask me, this bug is more
detrimental to the user experience than whether or not we can see the
volumes in our home folder.

[ma2412ma (ma2412ma)]

Hm, I'm not so sure that mounting user-space volumes outside of the home folder is a no-no - if there's a folder for that purpose, I think it should be used to mount also the .gvfs stuff (just as it is used now to mount USB drives and so on). There are some folders outside the home that are writeable for non-root users (such as /tmp) right now. So why not mount everything in /media?

Second, it seems to me that all non-Gnome applications would benefit from this. Since not even all Gnome apps can handle it now (gedit), this would be really helpful. My second example went unheard - OpenOffice.org. It's strange that emacs supports gvfs, probably a Gnome GUI version? Can you really open a text file from nautilus on an smb:// address and emacs doesn't complain?

Seems stupid to me to "enhance" each program with the gvfs support when it'd be so easy to just mount the SSH/samba/FTP/... stuff to a regular location in the file system hierarchy - IMHO, gvfs would be a real killer feature then.

BTW, this discussion does not belong to this bug report any more, is there a more suitable location for it?

[Ross Peoples (deejross)]

ma2414ma: don't waste your time, they are totally unwilling to see reason no matter how many examples you give. They refuse to admit there is a problem.

[Jeremy Cantrell (jmcantrell)]

i'm sorry, i completely disagree. user-space tools should not be
polluting the rest of the system. having a directory, like /tmp, that
is writable by everyone is not the same thing as having a directory
that is owned by some specific user.

not to mention, i may have my home folder permissions set so that i'm
the only one that can read files. if i mount some share with fuse, i'm
expecting it to be just as protected as any of my other files, whereas
if it were in something like /media, it would likely not be.

the reason why the file system hierarchy is so nice is because i know
(as the one who has root access to a particular machine) that all
files related to a particular user are going to be in that user's home
folder (as defined in /etc/passwd), instead of spread out all over the
system.

[Sebastien Bacher (seb128)]

nobody deny there is some issues, but having implementation details showed to user might not be the best changer to do there, anyway somebody should open a new gvfs bug about the issue

[Jeremy Cantrell (jmcantrell)]

yes, there is a problem. it's called "Bug 212789", which this
silliness has nothing to do with. the file system hierarchy is there
for a reason. try to resist the urge to fight it.

[Ross Peoples (deejross)]

jmcantrell: There didn't seem to be a problem adding the folders Music, Pictures, Videos, etc to the user's home directory. I'm not fighting the directory structure. You'd know that if you read the whole thread. I'm done arguing with your close mindedness.

Sebastien: Perhaps showing the implementation details isn't the best idea, I agree with you. However, until the problem with applications playing nicely with gvfs is fixed, there should be some kind of work around, even if only temporary. I would file another bug report, but opinions from users with legitimate ideas seem to get flamed quite quickly. I'll use jmcantrell's latest response as the example.

[Sebastien Bacher (seb128)]

one of the changes that would make things smoother is http://bugzilla.gnome.org/show_bug.cgi?id=528670 for example, but this discussion should really be moved to an another bug now

[Jeremy Cantrell (jmcantrell)]

ross: oh? because i prefer simplicity and standards over entertaining
every goofy "enhancement" that comes along, i am close minded? wow...
and since we're on the topic, i actually find the automatic creation
of those various folders to be frivolous and unnecessary. if a user
wants a music directory, is it really that difficult to just create
it?

[ma2412ma (ma2412ma)]

I admit that this discussion does not belong to this bug any more and that's why some people refuse to see the problem. Has anyone of you (jmcantrell, Sebastien) actually read my last comment? Let's quit it and if someone suggests a more suitable place to continue this discussion, I'd be happy to join in.

[Jeremy Cantrell (jmcantrell)]

i would be glad to continue this over an email thread. if anyone wants to continue the discussion, please include me (jmcantrell [at] gmail [dot] com).

[jhansonxi (jhansonxi)]

This bug is causing a security issue for me. I'm using pam_mount to unlock and mount a LUKS/dm-crypt volume to my home directory at login. At logout it doesn't unmount and lock because fuse.gvfs has ~/.gvfs open. The script suggested in comment #14 did not solve the issue.

[Øyvind Stegard (oyvindstegard)]

jhansonxi wrote:
This bug is causing a security issue for me. I'm using pam_mount to unlock and mount a LUKS/dm-crypt volume to my home directory at login. At logout it doesn't unmount and lock because fuse.gvfs has ~/.gvfs open. The script suggested in comment #14 did not solve the issue.

Try it without the surrounding if-test, just use:

/bin/fusermount -zu "$HOME/.gvfs" 1>/dev/null 2>&1 || true

I fixed that myself, because the surrouding if-test will fail if the gvfs fuse-daemon has died, which unfortunately happens quite often.

[Sebastien Bacher (seb128)]

the bug has been fixed upstream and a new version should be uploaded tomorrow as an hardy update candidate

[Martin Pitt (pitti)]

Accepted into -proposed, please test and give feedback here

[Jeremy Cantrell (jmcantrell)]

seems to have fixed the issue for my systems. the only thing i tested was the login/logout problem.

[Martin Pitt (pitti)]

Copied to intrepid.

[Martin Pitt (pitti)]

New version works well for me on hardy-proposed, I can still browse network shares and get ~/.gvfs mounts.

[Pedro Villavicencio (pedro)]

New version also works fine here, which means i can browse my network shares after logout/login, bug is fixed, thanks.

[Martin Pitt (pitti)]

Copied to hardy-updates.

[Matthias (m-kaeppler)]

Does this also fix the problem with CIFS mounts?

They are not properly unmounted on logout either, resulting in the system hanging on logout waiting for server responses and flooding the terminal with CIFS communication errors.

One has to manually unmount them before logout to circumvent this.

[Ryan Waldroop (ryan.waldroop)]

The fix in hardy-proposed doesn't seem to fix my ftp mounts. They still disappear and I have to re-mount them after logout/login. Is that supposed to work that way? It's really annoying and seems like a definite regression from Feisty/Gutsy. I much prefer having my ftp mounts stay available.

Please take a look at bug 235390 (https://bugs.launchpad.net/ubuntu/+bug/235390 for email users) for more info on my problem. Is that a definite duplicate? Sorry if it is, I couldn't find this bug because I wasn't sure what package to search for.

[Hugh G. Rection (cmanley-deactivatedaccount)]

The latest 'fix' doesn't fix the bug for me. This is my situation for if you want to try to reproduce it:

1. Make a Samba share on another server. Mine are unpublished i.e. you don't see them when browsing the network, but you can "cd" and log into them after which they become visible in Nautilus.
2. Use Gnome Commander to open a source code file in gedit.
3. Edit and save the file. After a couple of saves at most you get a "Transport endpoint is not connected" error and an "ls -al" of the .gvfs directory returns this:
d????????? ? ? ? ? ? .gvfs

[Hugh G. Rection (cmanley-deactivatedaccount)]

Elaboration about point 2 above: I use Gnome Commander to open a source code file by navigating via the ~/.gvfs directory

[Sebastien Bacher (seb128)]

those new comments are a different issue, did you read the bug title before commenting?

[Olivier Tilloy (osomon)]

I’m seeing this issue in Natty.

It is a fresh install, my home directory is encrypted and it has annoying consequences, such as Déjà-Dup failing to backup my home directory because of ~/.gvfs ("Transport endpoint is not connected"). And since the .gvfs folder cannot be browsed to, I can’t even add it to the list of excluded directories in Déjà-Dup (I figured out how to work around this by manually editing the corresponding GConf key though).

    osomon@granuja:~$ LANG=C cd .gvfs
    bash: cd: .gvfs: Transport endpoint is not connected

    osomon@granuja:~$ mount | grep gvfs
    gvfs-fuse-daemon on /home/osomon/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=osomon)

Should I re-open this bug, or should I file a new one?

[Florian Rathgeber (florian-rathgeber)]

I can confirm the bug on natty with the same symptoms that osomon is seeing.

[Gaëtan Duchaussois (gaetan-duchaussois)]

I have the same behaviour as osomon, pretty annoying. is there any chance to get it fixed?

[d4v1dv00 (davidvoo)]

quick workaround is:

$ sudo -i
Password:
# fusermount -u /root/.gvfs
#exit
$ df -h

[einar.kristian (einar-kristian)]

Tried davidvoo quick workaround, but it didn’t work.

[Victor Yap (victor-yap)]

Leveraging off oyvinst's script (comment #14)...

I worked around this bug by doing a little bit more:

# Quick and dirty hack to unmount ~/.gvfs directory on logout.
if test -d "$HOME/.gvfs" ; then
  for f in "$HOME/.gvfs"
  do
    /bin/fusermount -zu "$HOME/.gvfs/$f" 1>/dev/null 2>&1 || true
  done
  /bin/fusermount -zu "$HOME/.gvfs" 1>/dev/null 2>&1 || true
  rmdir "$HOME/.gvfs"
fi

... the script's written from gut-feeling and I didn't actually go through the steps to troubleshoot any bugs in its logic... >_> I applied this for Ubuntu 11.10 ... my quickfix intuition is that the .gvfs folder should be recreated from scratch on session login for the gvfs magic to work, even after doing the initial unmount... If someone could instead point out what command(s) are used to do the magic service's initialization, we might be able to "restart" it within a session instead of cycling through "logout -> login".

[Henrique Sanches Quartarollo (rique-svc)]

Send fix to me

[MSE (mseslacker)]

I'd like to confirm sighting of the .gvfs "Transport endpoint is not connected" bug in Xubuntu 11.10 Oneiric.

The problem is as described in the post from 2008-06-20 in this thread:
Thunar won't show the contents of /home/ubuntu, due to the issue with .gvfs .
And ls -la of /home/ubuntu shows broken permissions for .gvfs :
d????????? ? ? ? ? ? .gvfs

Additionally, I see the same broken permissions on /etc/mtab and ~/.bash_history . I can "fix" the broken permissions on ~/.gvfs with "umount .gvfs". But, due to the corruption related to .bash_history , Thunar still will not display the contents of $HOME. It fails with:
Error stating file '/home/ubuntu/.bash_history': Input/output error.

Corruption in mtab prevents Thunar from displaying the contents of /etc :
"Error stating file '/etc/mtab': Input/output error."
On the command line, a simple attempt to see what's in mtab with "sudo cat /etc/mtab" results in:
cat: /etc/mtab: Input/output error

Now, I'm far from an expert in these matters.
But I suspect that losing I/O access to mtab, even for root, is not a good or desirable feature.

I'm running a more or less out-of-the-"box" Xubuntu Live install from a USB drive.
This is a stock Oneiric install, as installed to an 8GB Kingston DataTraveler drive by Universal USB Installer, with 2GB persistence file. It's running on an Asus branded Intel Atom eeePC netbook.

The workaround from this thread (posted originally on 2008-04-27 and re-visited more recently on 2011-11-07) has been reposted various places around the 'net:
fusermount -zu ~/.gvfs
from eg.,
http://razcx.wordpress.com/2011/11/03/cannot-access-gvfs-transport-endpoint-is-not-connected/ and
http://r3dux.org/2011/08/how-to-workaround-gvfs-transport-endpoint-is-not-connected-errors/

But this doesn't address whatever the underlying problem is with GVFS.
It appears that this has been a known bug in GVFS since early 2008, when this thread was opened, and an identical bug was reported in the Fedora 9 forums:
https://bugzilla.redhat.com/show_bug.cgi?id=452304

[klakier (insane-vx)]

I confirm the very same bug on 64-bit Oneiric

[NoOp (glgxg)]

And present in 12.04.
$ apt-cache policy gvfs
gvfs:
  Installed: 1.12.1-0ubuntu1
  Candidate: 1.12.1-0ubuntu1
  Version table:
 *** 1.12.1-0ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

[Cornelius Sicker (ysis)]

Still present in 12.04 64bit.
$ apt-cache policy gvfs
gvfs:
  Installed: 1.12.1-0ubuntu1.1
  Candidate: 1.12.1-0ubuntu1.1
  Version table:
 *** 1.12.1-0ubuntu1.1 0
        500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.12.1-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

[Andreas (andreas-kotowicz)]

I still have this problem with Ubuntu release 10.04 64bit.

$ apt-cache policy gvfs
gvfs:
  Installed: 1.6.1-0ubuntu1build1
  Candidate: 1.6.1-0ubuntu1build1
  Version table:
 *** 1.6.1-0ubuntu1build1 0
        500 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
        100 /var/lib/dpkg/status
     1.6.0+git20100414-0ubuntu1 0
        500 http://de.archive.ubuntu.com/ubuntu/ lucid/main Packages

Furthermore, I can't unmount the .gvfs directory using 'fusermount':
$ fusermount -zu ~/.gvfs
 fusermount: failed to chdir to /home/user: Permission denied