Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm setting up a backup of my linux-based webserver to a NAS running FreeBSD. I've created a backup user on the FreeBSD box and ran rsync as root on the local (web server) box using the following command:

rsync -avz /hsphere/ backup_user@192.168.1.253:/mnt/tank/web_backup/web01.webhost.net

It works fine for all directories owned by root, but when it starts backing up the directories owned by ordinary users, I get permission denied errors.

rsync: recv_generator: mkdir "/mnt/tank/web_backup/web01.webhost.net/hsphere/local/home/username/username.com" failed: Permission denied (13)

I was guessing this is because the "-a" tries to preserve the ownership of the original files, and since those users don't exist on the remote server, it was refusing it. I tried running rsync without the -o -g and -p flags thinking that would get around it, but I get the same error.

rsync -rltDz /hsphere/ backup_user@192.168.1.253:/mnt/tank/web_backup/web01.webhost.net

If I rsync using root for the remote NAS, it does succeed, but I would rather not have to use root on the NAS if I can avoid it since it creates a security hole. The "backup_user" on the freebsd box is in the wheel group, which should give him sufficient permissions.

Any advice on how to proceed?

share|improve this question
add comment

1 Answer

You may want to try --fake-super. From the rsync man page:

--fake-super

When this option is enabled, rsync simulates super-user activities by saving/restoring the privileged attributes via special extended attributes that are attached to each file (as needed). This includes the file's owner and group (if it is not the default), the file's device info (device & special files are created as empty text files), and any permission bits that we won't allow to be set on the real file (e.g. the real file gets u-s,g-s,o-t for safety) or that would limit the owner's access (since the real super-user can always access/change a file, the files we create can always be accessed/changed by the creating user).

In your case, since you want to use --fake-super on the remote side, you will need to invoke it via --rsync-path, e.g.:

rsync -avz --rsync-path='rsync --fake-super' /source/ backupuser@remote:/dest/

When restoring from your backups, you will also need to ensure that --fake-super is always in force on the system where the backups are stored.

share|improve this answer
    
Thanks for the suggestion. I got the same error with the fake-super added in though. –  John P May 24 '11 at 11:42
    
@John P: Is it possible that you have a previous partially-completed backup interfering with your latest attempt? If so, remove your entire backup directory tree and try again with --fake-super. –  Steven Monday May 24 '11 at 20:20
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.