[SOLVED] What is .gvfs? Weird directory entry

haertig · 09-17-2013, 09:33 PM

What is this strange .gvfs entry? The ls output looks bizare. I am assuming it has something to do with VirtualBox. Which I recently installed, created a VM, and the user is probably running at this time (either running, or in a "saved state").

Code:

# id
uid=0(root) gid=0(root) groups=0(root)

# mount
/dev/sda6 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda5 on /home type ext4 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/user1/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=user1)

# ls -al /home/user1 | grep .gvfs
ls: cannot access /home/user1/.gvfs: Permission denied
d?????????  ? ?     ?         ?            ? .gvfs

# ps -ef | grep gvfs
user1     1461     1  0 Sep13 ?        00:00:00 /usr/lib/gvfs/gvfsd
user1     1463     1  0 Sep13 ?        00:00:00 /usr/lib/gvfs//gvfs-fuse-daemon -f /home/user1/.gvfs
user1     1507     1  0 Sep13 ?        00:00:00 /usr/lib/gvfs/gvfs-gdu-volume-monitor
user1     1533     1  0 Sep13 ?        00:00:00 /usr/lib/gvfs/gvfs-afc-volume-monitor
user1     1536     1  0 Sep13 ?        00:00:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
user1     5195     1  0 Sep14 ?        00:00:00 /usr/lib/gvfs/gvfsd-http --spawner :1.4 /org/gtk/gvfs/exec_spaw/0
user1    19891     1  0 Sep16 ?        00:00:00 /usr/lib/gvfs/gvfsd-metadata
root     22091 21951  0 20:27 pts/0    00:00:00 grep --colour=auto gvfs

#

haertig · 09-17-2013, 09:40 PM

This is how I first noticed it, a non-trivial discrepancy between the size of /home as reported by df vs. du (plus the unexpected "permission denied" for root):

Code:

# pwd
/home

# df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5       100G  5.0G   90G   6% /home

# du -sh .
du: cannot access `./user1/.gvfs': Permission denied
3.4G	.

#

rknichols · 09-17-2013, 09:52 PM

It is a virtual filesystem used by the internals of the Gnome desktop. The contents have meaning only for the user and the Gnome session that created it, and even root cannot look inside it. Ignore it. It uses no space on disk. (The empty directory where it is mounted uses 1 disk block, of course.)

haertig · 09-17-2013, 10:15 PM

OK. Although this system does not have Gnome installed on it (it uses Xfce only, with no other installed desktops). However, certainly there are bits and pieces of Gnome and KDE present. There always are (usually), no matter what desktop the distro uses.

TobiSGD · 09-18-2013, 04:26 AM

In fact, XFCE uses some Gnome technologies. GVFS is one of them.

yilez · 09-18-2013, 05:39 AM

GVFS (Gnome Virtual File System) is used to mount remote file systems (like samba shares) and things like that. As mentioned above, XFCE uses this instead of creating its own thing, as it also does with networkmanager applet and other things.

FYI, my KDE desktop also implements GVFS. Or at least I have the following mount point:

gvfs-fuse-daemon on /home/rover/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=rover)

haertig · 09-18-2013, 11:20 AM

On a different system (see below), running the identical version of the OS (LinuxMint_13_Maya_Xfce_x64) I see the .gvfs mount, but the "ls -l" output on the directory is normal (mode 500). The "ls -l" output on the other system (see initial post) appears corrupted. What's up with that? I would think an fsck might be in order on the system with the corrupted looking "ls -l" output.

Code:

$ mount                                            
/dev/sda4 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/user2/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=user2)

$ ls -al | grep gvfs
dr-x------  2 user2 user2     0 Sep 17 11:49 .gvfs

$

Compare the two systems:

Code:

# ls -al /home/user1 | grep .gvfs
ls: cannot access /home/user1/.gvfs: Permission denied
d?????????  ? ?     ?         ?            ? .gvfs

and

Code:

$ ls -al | grep gvfs
dr-x------  2 user2 user2     0 Sep 17 11:49 .gvfs

jpollard · 09-18-2013, 11:25 AM

The ??? are due to the gvfs daemon having died without dismounting. This is a side effect of using FUSE to implement the virtual filesystem.

The second has gvfs terminating normally, or (if you are logged in) still running.

rknichols · 09-18-2013, 01:06 PM

Note that in the first case ls was being run by root, which does not have access to the .gvfs filesystem for user1. In the second case, the ls was run by a non-root user, presumably user2, which does have access to its own .gvfs.

haertig · 09-18-2013, 02:45 PM

Quote:

Originally Posted by rknichols

Note that in the first case ls was being run by root, which does not have access to the .gvfs filesystem for user1. In the second case, the ls was run by a non-root user, presumably user2, which does have access to its own .gvfs.

Sure enough, that was it! I've never run into that before. I wasn't aware that a normal user operation could block root out of anything. Thanks!

Code:

$ id
uid=1000(user2) gid=1000(user2) groups=1000(user2),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),109(lpadmin),127(sambashare)

$ pwd
/home/user2

$ ls -al | grep gvfs
dr-x------  2 user2 user2     0 Sep 17 11:49 .gvfs

$ sudo su
[sudo] password for user2:
 
# ls -al | grep gvfs
ls: cannot access .gvfs: Permission denied
d?????????  ? ?     ?         ?            ? .gvfs

#

rknichols · 09-18-2013, 05:21 PM

FYI, those question marks do not indicate an error in the filesystem. When the ls command run by root issues a stat(2) system call to get the information for that directory, the call fails with EPERM (permission denied). The ls command is just displaying question marks for the information it could not retrieve. (There is a tag in the parent directory that indicates that .gvfs is a directory, but that is the only information available to the root UID.)