48

Can someone tell me what I'm doing wrong, what this is, or how to fix it? I'm running Fedora 18 and getting the error shown

[root@servername /]# find . -name ngirc
find: `./run/user/1000/gvfs': Permission denied
[root@servername /]# 
[root@thinktank /]# pwd
/
[root@thinktank /]# ls -ltr ./run/user/1000
ls: cannot access ./run/user/1000/gvfs: Permission denied
total 0
d?????????? ? ?    ?      ?            ? gvfs
lrwxrwxrwx. 1 root root  17 May 28 12:30 X11-display -> /tmp/.X11-unix/X0
drwx------. 2 kal  kal  120 May 28 12:30 keyring-QjDw4b
drwx------. 2 kal  kal   40 May 28 12:30 gvfs-burn
drwx------. 2 kal  kal   60 May 28 12:30 krb5cc_5f0bcaf94f916d6b61696e2251a4dbb3
drwx------. 2 kal  kal   60 May 28 18:25 dconf
Improve this question
1
  • You are not doing anything wrong and my suggestion would be to simply ignore the error. If that is not acceptable, how about excluding the GVFS mount point on the find command line?
    – tripleee
    Commented May 29, 2013 at 5:46

4 Answers 4

Reset to default
46

You aren't doing anything wrong, and there's nothing to fix. /run/user/$uid/gvfs or ~$user/.gvfs is the mount point for the FUSE interface to GVFS. GVFS is a virtual filesystem implementation for Gnome, which allows Gnome applications to access resources such as FTP or Samba servers or the content of zip files like local directories. FUSE is a way to implement filesystem drivers as user code (instead of kernel code). The GVFS-FUSE gateway makes GVFS filesystem drivers accessible to all applications, not just the ones using Gnome libraries.

Managing trust boundaries with FUSE filesystems is difficult, because the filesystem driver is running as an unprivileged user, as opposed to kernel code for traditional filesystems. To avoid complications, by default, FUSE filesystems are only accessible to the user running the driver process. Even root doesn't get to bypass this restriction.

If you're searching for a file on local filesystems only, pass -xdev to find. If you want to traverse multiple local filesystems, enumerate them all.

find  / /home -xdev -name ngirc

If the file has been present since yesterday, you may try locate ngirc instead (locate searches through a file name database which is typically updated nightly).

If you do want to traverse the GVFS mount points, you'll have to do so as the appropriate user.

find / -name ngirc -path '/run/user/*/gvfs' -prune -o -path '/home/*/.gvfs' -prune -o -name ngirc -print
for d in /run/user/*; do su "${d##*/}" -c "find $d -name ngirc -print"; done
Improve this answer
8
  • Thanks for the great explanation on GVFS and FUSE. I tried running 'find' like in your example and it worked great.
    – kal
    Commented May 30, 2013 at 4:00
  • How does FUSE prevent root from accessing the files? Surely root has the ability to disable such protections.
    – Akinos
    Commented Sep 25, 2015 at 4:37
  • 1
    @Nat Root can change its process's fsuid to the target uid, so in a security sense bypassing the protection is trivial. But the access control function in the kernel denies access to root. This phenomenon also happens with other filesystems, e.g. root can't access private directories on NFS without switching to the owner's UID.
    – Gilles 'SO- stop being evil'
    Commented Sep 25, 2015 at 8:04
  • 2
    to "avoid complications"... Well it sure created one huge complication since I cannot use the mount command to map the share path to a cleaner folder name.. Access denied to root when using sudo mount.
    – Nuzzolilo
    Commented Jan 1, 2016 at 8:56
  • @Nuzzolilo I have no idea what you're talking about. If you have a problem, ask a new question, and be sure to explain your scenario.
    – Gilles 'SO- stop being evil'
    Commented Jan 1, 2016 at 16:07
11

It's a fuse issue. No user except the owner can read. To work around the default configuration, try enabling the user_allow_other option. This option is specified by adding it to /etc/fuse.conf. It has no value, just specify the option on a blank line.

Improve this answer
3
  • Thanks. I don't really understand what fuse is, but after reading a bit from the bug report in your comment and don_crissti's comment, I'm guessing this has to do with a USB hard drive that I have plugged in or my samba server? Are there any security issues that I should consider when enabling "user_allow_other" and are there any other options for mounting that I should consider? Thanks.
    – kal
    Commented May 28, 2013 at 23:36
  • 1
    Thanks, but this isn't really a solution for me if nobody else can use the system. How can I tell who the owner is? I tried unmounting/disconnecting my external hard drive and shutting down my samba server. All I really want to do is be able to search the entire filesystem for a file without compromising the security. Is there an alternative to FUSE and is there a way to tell exactly what it's being used for? Thanks.
    – kal
    Commented May 29, 2013 at 1:51
  • askubuntu.com/questions/715637/… I tried the suggestion by @Christopher but the command line options are not being respected. I'm suspecting that the daemon auto launcher is configured a certain way but I cannot find the configuration documentation to do so
    – Nuzzolilo
    Commented Jan 1, 2016 at 19:06
5

If you are getting the permission and other details for gvfs as per the following 

d?????????? ? ?    ?      ?            ? gvfs

then just unmount your gvfs using the following command. Your issue will get resolve after following this process.

umount ~/gvfs(umount /run/user/112/gvfs in my case).

GVFS (GNOME Virtual File System) is the virtual file system for the GNOME desktop, which allows users easy access to remote data via SFTP, FTP, WebDAV, SMB, and local data via udev integration so you do not need to afraid while unmounting this.

Improve this answer
5

this is an old thread but in gnome bug reports it is a recent open issue so it may be of some use to anyone searching for hours for a solution to fix gvfs-fuser issues - which all seem to be tightly related.

Error Msg from meld:

Error copying '/media/root/5FDA03906F33F217/SAVE/rsyncTEST-usb/allusers' to '/run/user/0/gvfs/ftp:host=192.168.0.103/var/ftp/ftpd/images/PersistenceUSBs/rsync-meld/allusers'

[Errno 95] Operation not supported: '/run/user/0/gvfs/ftp:host=192.168.0.103/var/ftp/ftpd/images/PersistenceUSBs/rsync-meld/allusers'.

I encountered the gvfs-fuser issue attempting to use meld/diff/kdiff over ftp. Seems the problem is between fuser and gvfs. The problem seems not to occur in 3.15.1 but begins being reported in 3.15.2.(the new python ver?) Solution is a workaround not a fix - files/directories will copy but error is still displayed.

Christopher's answer defines the problem and provides the solution.

Another possible solution is using sshfs (see this comment and this thread). For more information on gvfs-commands, see What is the difference between gvfs commands and common commands like cat, ls, cp?

Possibly-related bugs include GNOME #317875 and GNOME #768281.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .