November 9, 2012
How FUSE Can Break Rsync Backups
Update: See my followup article, Easily Running FUSE in an Isolated Mount Namespace, for a solution to this problem.
FUSE is cool, but by its nature has to introduce some non-standard semantics that you wouldn't see with a "real" filesystem. Sometimes these non-standard semantics can cause problems, as demonstrated by a recent experience I had with rsync-based backups on a multi-user Linux server that I administer.
The server performs regular snapshot backups of the filesystem using rsync and its --link-dest option to provide hard link-based dedupe. One day, an enterprising user mounted a sshfs filesystem in his home directory. That night, the snapshot backup failed with this error message:
rsync: readlink_stat("/home/aganlxl/cit") failed: Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1060) [sender=3.0.7]The problem is that, by default, only the user who owns the FUSE mount is allowed to access it. Not even root can. This is a security measure, since a malicious user could wreck havoc with a malicious FUSE mount (imagine an infinite filesystem, for example).
This behavior can be changed (with the 'allow_root' mount option, which has to be explicitly enabled by the super user in fuse.conf), but that's not the answer. Besides the security implications, that would cause rsync to descend into the sshfs mount and start backing up the remote system!
The problem is that rsync needs to be able to access everything it's backing up. Running as root, this is usually not a problem. Root not being able to access something on the filesystem seems weird, but is actually nothing new - root-squashed NFS mounts can also cause this. But FUSE mounts are worse. To begin with, unlike root-squashed NFS mounts, users are allowed to plop down FUSE mounts anywhere they like.
But worse, root isn't even allowed to stat FUSE mounts. This means that rsync's -x option (to not cross filesystem boundaries) can't even be used to exclude FUSE mounts, since rsync needs to stat the directory to determine if it's a mount point! This behavior is outside of POSIX, which says that stat shall return EACCES if "search permission is denied for a component of the path prefix."
In my opinion, a worthwhile addition to fuse.conf would be an option to restrict FUSE mounts to specific directories. With such an option, the admin could restrict FUSE mounts to locations that aren't backed up.
Until then, FUSE is disabled on this particular server.
Post a Comment
Your comment will be public. To contact me privately, email me. Please keep your comment polite, on-topic, and comprehensible. Your comment may be held for moderation before being published.
Comments
Reader Bruno on 2013-09-11 at 07:46:
I found this article when I encountered the same problem (and frustration). But I almost missed your follow-up article, which is interesting too, so I mention it here explicitly: "Easily Running FUSE in an Isolated Mount Namespace"
Reply
Andrew Ayer on 2013-09-12 at 00:15:
Thanks for pointing this out; I just updated this article to include a link to my followup.
Reply
Reader nu2Lx on 2016-04-25 at 03:28:
Even though this post is almost 4 yrs old, I still have to ask this question.
I'd like to back up root on Mint Cinnamon 17.2 using Grsync. My media file system reads: fs: fuseblk. I am the sole user of this computer with admin rights. Will I have any problems using Grsync for this kind of backup?
Reply