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 am trying to use rsync to copy a backup folder on a local machine to another machine daily (in case of data loss or accidental deletion). This runs as a cronjob.

I just the command

rsync -av --rsh='ssh -p90' --delete /backup/ tentbackup@server.pezcuckow.com:~/dabackup/

From the root account on server one (tent).

However on the first server the permissions on each of the subdirectories are set so that you can't get into them unless you are root (no execute permission on the folders), this is something I cannot change easily as it is how the backup software works.

This means that on the second server (server.pezcuckow.com) the account tentbackup doesn't have permission to go into the folders that rsync is creating resulting in the following errors

root@tent:~$ rsync -av --rsh='ssh -p92' --delete /backup/ tentbackup@server.pezcuckow.com:~/dabackup/
building file list ... done
03-05-11/apache/
rsync: recv_generator: mkdir "/home/tentbackup/dabackup/03-05-11/apache" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
03-05-11/bind/
rsync: recv_generator: mkdir "/home/tentbackup/dabackup/03-05-11/bind" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
03-05-11/custom/
rsync: recv_generator: mkdir "/home/tentbackup/dabackup/03-05-11/custom" failed: Permission denied (13)
etc...

I could work around this problem using root@server.pezcuckow.com (server two) but obviously I don't want ssh keys for the root account stored on server one (tent).

How do I safely allow rsync permission to create these subfolders and files?


Even when logged into server two directly as tentbackup I cannot move into the directories or make files inside them

tentbackup@brave:~/dabackup$ cd 03-20-11/
bash: cd: 03-20-11/: Permission denied
tentbackup@brave:~/dabackup$ mkdir 03-20-11/test -p
mkdir: cannot create directory `03-20-11': Permission denied
tentbackup@brave:~/dabackup$ touch 03-20-11/test
touch: cannot touch `03-20-11/test': Permission denied
share|improve this question
    
What is the output of ls -ld /home/tentbackup/dabackup/? –  quanta Aug 28 '11 at 12:53
    
drwx--x--- 80 tentbackup tentbackup 4096 2011-08-28 04:00 /home/tentbackup/dabackup/ –  Pez Cuckow Aug 29 '11 at 15:23
add comment

3 Answers

You are trying to do something that is specifically prohibited by the set permissions. You either have to change the set permissions or give your program special privileges. One fix might be to create a cron job on the server that fixes the directory permissions. Alternatively, you could have a program that runs as root that waits for a command from the ssh script and fixes the directory permissions.

share|improve this answer
add comment

You should be able to do this by dropping the -a flag from rsync and using whatever flags you need instead. Logically from the configuration you don't want to do this as root which means you need to ignore permissions on the destination side. Make sure you don't include -p in the rsync command and you should be able to copy the files safely from root@serverone to user@servertwo and it should be able to create dirs etc. Just remember your permissions tree won't be there on servertwo if you need to restore from backup, that should be pretty easy to write a script to fix I hope.

Otherwise you will need to get special access to create and manage the files on servertwo, you could accomplish this by setting up rsyncd.conf and using rsync in daemon mode so you wouldn't need to allow ssh between the two hosts(its unclear from the question if perhaps other users have access to the host so that may not be secure enough).

share|improve this answer
add comment
up vote 1 down vote accepted

The correct way to do this (though it does change the permissions so you can't just restore from backup if these were important) is to add the following to your rsynccommand

--no-p --no-g --chmod=ugo=rwX

Where

--no-p disables permissions copying

--no-g disables group copying and

--chmod=ugo=rwX ensures that all non-masked bits get enabled

share|improve this answer
    
1+ but why not rwx instad of rwX? –  rahmanisback Jul 31 '13 at 6:09
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.