root user denied access to .gvfs in rsnapshot?

Question

I was running rsnapshot as root and I got the following error. Why would this happen? what is .gvfs?

rsnapshot weekly                                                                    slave-iv
rsync: readlink_stat("/home/griff/.gvfs") failed: Permission denied (13)
IO error encountered -- skipping file deletion
rsync: readlink_stat("/home/xenoterracide/.gvfs") failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1042) [sender=3.0.7]

Solution

.gvfs directories are mount points (sometimes). You may want to use the one_fs option in your rsnapshot configuration (so that it passes --one-file-system to rsync).

---

Gvfs is a library-level filesystem implementation, implemented in libraries written by the Gnome project (in particular libgvfscommon). Applications linked with this library can use a filesystem API to access ftp, sftp, webdav, samba, etc.

Gvfs is like FUSE in that it allows filesystems to be implemented in userland code. FUSE requires the one-time cooperation of the kernel (so it's only available on supported versions of supported OSes), but then can be used by any application since it plugs into the normal filesystem API. Gvfs can only be used through Gnome libraries, but doesn't need any special collaboration from the kernel so works on more operating systems.

A quick experiment on Ubuntu 10.04 shows that while an application is accessing a Gvfs filesystem, ~/.gvfs is a mount point for a gvfs-fuse-daemon filesystem. This filesystem allows any application to access Gvfs filesystems, without needing to link to Gnome libraries. It is a FUSE filesystem whose implementation redirects the ordinary filesystem calls to Gvfs calls.

The gvfs-fuse-daemon filesystem does not allow any access to the root user, only to the user running the application (it's up to each individual filesystem to manage the root user's permissions; a classic case where root doesn't have every power is NFS, where accesses from root are typically mapped to nobody).

Comments

[Admin]

Is your home on an NFS filesystem, by any chance?

[Admin]

@Gilles nope, ext4

[Admin]

Ok, let's have more data: OS? permissions on the .gvfs directories (ACLs if relevant, etc.)? Are they actually mount points?

[Admin]

@Gilles Arch Linux. I don't use ACL's (so unless automagically set), mine is empty and nothing in df about it being mounted. dr-x------ 2 xenoterracide users 0 Oct 24 14:47 .gvfs

[Admin]

ls -la .gvfs slave-iv total 4 dr-x------ 2 xenoterracide users 0 Oct 24 14:47 . drwx------ 46 xenoterracide users 4096 Oct 29 18:32 ..

[Admin]

@xenoterracide: df doesn't show filesystems that advertise a total size of 0. Try df -a or df ~/.gvfs or grep gvfs /proc/mounts.

[Admin]

@Gilles ah... yep gvfs-fuse-daemon has it mounted...

[xenoterracide]

%$#@! gnome! I don't even use gnome! prolly chrome or pidgin creates this... hmm... I'm not particularly concerned that it's not backing up, they aren't seemingly being used anyways.

[xenoterracide]

just as a note I just tried one_fs and still received the error.

[Gilles 'SO- stop being evil']

@xenoterracide: You might not use the Gnome desktop environment, but you are using applications that link against Gnome libraries. There might be a way to tell Gnome not to start the daemon, I haven't looked. I suspect that the one_fs option isn't working because rsync is somehow getting a permission denied as part of its check as to whether .gvfs is a mount point.

[xenoterracide]

:S this would be really annoying if it were a cron job, because it would be emailing me each time. I wonder if an --exclude would work.

[Martin Schröder]

@xenoterracide: --exclude works.

[psusi]

Way to necro a long dead question, but 1) this is how gvfs works, it is not something the questioner did and 2) this does not answer the question. Also dump does not know or care about mount points, either in your home dir or otherwise.