I am trying to backup several servers' /etc by using rsync from another server. Here's a relevant snippet:

RSYNC_OPTS="--archive --inplace --no-whole-file --quiet"
ssh -n -i $PRIVKEY root@${ip} "rsync $RSYNC_OPTS /etc"'$(hostname)'

where ${ip} is the IP Address of the server to be backed up, while is the IP Address of the server holding the backup.

Everything went well, except for /etc/{,g}shadow files on some servers. Since their permissions are 0000, rsync seems to not want to read them ("Permission denied (13)" errors).

A quick check using the following:

ssh -i $PRIVKEY root@${ip} "cat /etc/{,g}shadow"

successfully dumped the files.

Is there a way to get round this rsync limitation?


The backup server is Ubuntu 12.04. The servers to be backed up are a smorgasbord of Ubuntu, RHEL, OEL, and CentOS servers.

I've tried adding -t to the ssh options, and prefixed rsync with sudo, but still have the same errors.

  • What platform are you on? – Kevdog777 Dec 6 '13 at 14:34
  • @Kevdog777 sorry, I forgot. I'll add more info. – pepoluan Dec 6 '13 at 14:41
  • What EUID are you working as on the server you are rsync'ing to? If that user doesn't have permissions to create a file with no permissions (i.e. if you aren't rsyncing as root) then this won't work. – sparticvs Dec 6 '13 at 15:01
  • @sparticvs on the Backup Server ( where I triggered the backup script, I'm running as root (EUID=0). – pepoluan Dec 6 '13 at 15:10
  • @pepoluan are you getting the error on RHEL, OEL, and CentOS only? Or is it also on Ubuntu? I am wondering if selinux policy is causing the issue (apparmor might be protecting it as well) – sparticvs Dec 6 '13 at 15:17

File permissions do not really apply to root: Programs running as root can read and write files regardless of protection settings. (However, even root cannot execute a file unless one of the execute bits is set; it does not matter which one). That explains why cat can do it. But apparently, rsync runs its own check in order to rein in what might get copied. So it's not a "limitation" but intended behavior (not that it's any consolation to you). I say "apparently" because I haven't found any documentation for this behavior.

(Apologies if I'm just restating your question! Not quite sure from your description.)

If your problem is limited to the shadow files, I'd be inclined to add the call to cat to your backup script, and ignore the rsync error for these files. You could add logic to only sync the shadow files when they've changed, but really they're small enough that I wouldn't bother.

  • =le sigh= ... okay, if it's not workable on rsync, I guess I'll just have to separately copy the shadow files, then. Thanks! – pepoluan Dec 9 '13 at 9:53

I can't tell you precisely why your rsync is failing, because the rsync copy works in my systems.

However, I can give you a recipe for determining why the rsync fails. As root on the server to be backed up:

cd /tmp
echo foo > tst
chmod 0000 tst
strace -fo strace-cat.out \
    cat tst
strace -fo strace-rsync.out \
    rsync -av --quiet tst tst.2
# set RSYNC_OPTS and hostname before executing following
strace -fo strace-remote-rsync.out \
    rsync $RSYNC_OPTS --quiet tst

This splits the problem into three parts - a successful local open/read/close for cat, a local rsync (which might succeed) and a remote rsync, which will fail as yours is doing.

You'll be able to see from the strace output in strace-remote-rsync.out (and maybe strace-rsync.out) which system call is failing. And you'll see that rsync is a much more complex operation, with sub-processes, and different I/O. It uses mmap(2) to load the file into memory, rather than open(2) to obtain a file descriptor for it.

  • Thanks for the insight and nice tip! I think I'll just implement @alexis's suggestion, and separately copy the shadow files using a remote cat. – pepoluan Dec 9 '13 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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