Description of problem: gvfs share no longer a available through the folder /run/user/1000/gvfs, but available for GTK3 applications such nautilus and gedit. Demonstration: https://drive.google.com/file/d/0B0nwzlfiB4aQbjFuZGFJZ2YxRmM/view?usp=sharing (please use Google Chrome for HD quality) $ rpm -qa | grep gvfs gvfs-archive-1.24.1-2.fc22.x86_64 gvfs-gphoto2-1.24.1-2.fc22.x86_64 gvfs-debuginfo-1.24.1-2.fc22.x86_64 gvfs-mtp-1.24.1-2.fc22.x86_64 gvfs-1.24.1-2.fc22.x86_64 gvfs-afp-1.24.1-2.fc22.x86_64 gvfs-afc-1.24.1-2.fc22.x86_64 gvfs-fuse-1.24.1-2.fc22.x86_64 gvfs-goa-1.24.1-2.fc22.x86_64 gvfs-smb-1.24.1-2.fc22.x86_64
Thanks for your bugreport. It seems from your screencast it might be somehow sftp-specific, because fuse folder for mtp mount is shown correctly, mightn't it? However it works correctly for me with sftp on F22 with the same version of GVfs. I suppose you are able to reproduce it when you recorded the screencast. Could you make more investigation what shares are affected? Could you provide more info how it can be reproduced? It might be useful to get the log from gvfs daemon. Please do following steps: 1/ GVFS_DEBUG=1 /usr/libexec/gvfsd --replace &> ~/gvfsd.log 2/ mount the affected share 3/ try to access the fuse mount point 4/ attach the gvfsd.log from your home directory
1. reboot system 2. do GVFS_DEBUG=1 /usr/libexec/gvfsd --replace &> ~/gvfsd.log because if I do this after problem occurs issue is gone 3. mount 213.136.82.171 all fine 4. mount 81.30.214.93 in nautilus all ok. Geany can't open file in Midnight Commander folder ?sftp:host=81.30.214.93,port=21212,user=crmdev marked red color and I can't enter inside Log is here
Created attachment 1058033 [details] gvfsd.log
Today I moved to Fedora 23 problem still happens
Created attachment 1060781 [details] gvfsd.log
Thanks for the logs, unfortunately I don't see anything abnormal there. It might be also kernel/fuse bug, but hard to say. Is is specific to sftp shares, or not? Or is it even specific only for 81.30.214.93 share? Did you make fresh installation of F23, or just upgrade? Are you able to reproduce it with live system?
Bad news seems the problem is floating. After restarting it disappeared. But one thing I can say it is directly related with the catalog /run/user/1000/gvfs when the problems start required share is not available or can't enter inside as described in first post.
Is the first mount still fine after the second was broken? What is output of the following commands when the problem occurs? $ pgrep -a gvfsd-fuse $ mount | grep fuse $ ls -l /run/user/1000/gvfs fuse-2.9.4 was released recently, would by nice to test this against fuse-2.9.3. Could you retest this with downgraded fuse and fuse-libs?
Output from the commands was already provided by another user upstream. It shows that gvfsd-fuse daemon is still running. Lets close this bug and move our discussion on one place: https://bugzilla.gnome.org/show_bug.cgi?id=753561
[mikhail@localhost .config]$ pgrep -a gvfsd-fuse 2092 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes [mikhail@localhost .config]$ mount | grep fuse gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) [mikhail@localhost .config]$ ls -l /run/user/1000/gvfs ls: cannot access /run/user/1000/gvfs/sftp:host=81.30.214.93,port=21212,user=crmdev: No such file or directory total 4 dr-xr-xr-x. 1 mikhail mikhail 4096 Jun 3 05:01 sftp:host=213.136.82.171,user=synergy-demo ??????????? ? ? ? ? ? sftp:host=81.30.214.93,port=21212,user=crmdev [mikhail@localhost .config]$ rpm -q fuse fuse-2.9.4-2.fc23.x86_64