I use this rsync invocation to backup my home directory:

rsync -aARrx --info= --force --delete --info=progress2 -F "$USER_HOME" "$BACKUP_MNTPOINT"

rsync man page says that -a implies -g and -o (among other switches), which should preserve ownership. However I've noticed that if a directory does not exist under $BACKUP_MNTPOINT/$USER_HOME, it is created with root:root ownership instead of the correct one. (This only happens with directories right under $BACKUP_MNTPOINT/$USER_HOME). Why is that?

$BACKUP_MNTPOINT is a localy mounted drive. $BACKUP_MNTPOINT/$USER_HOME does have the right ownership and permissions. Neither $USER_HOME nor $BACKUP_MNTPOINT end with a slash.

Both the source and the target filesystems are XFS and running mkdir $BACKUP_MNTPOINT/$USER_HOME creates a directory with the expected ownership.

  • 1
    What filesystem is $BACKUP_MNTPOINT and with what options is it mounted? Does this happen only for the parent ($BACKUP_MNTPOINT/$USER_HOME) directory or for all directories created? Do $BACKUP_MNTPOINT and $USER_HOME end with a /? – terdon Nov 1 '14 at 13:21
  • I use XFS for both /home and the backup drive. So far I think it only happened for the parent directories. Neither $BACKUP_MNTPOINT nor $USER_HOME end with a slash. EDIT: I can confirm now it only happens to the directories right below $BACKUP_MNTPOINT/$USER_HOME – kralyk Nov 1 '14 at 13:32
  • So $BACKUP_MNTPOINT/$USER_HOME has the right permissions but any subdirectories do not? Please edit your question and add these details. Also, clarify whether mkdir $BACKUP_MNTPOINT/$USER_HOME/foo creates a directory owned by your user if you do it manually. – terdon Nov 1 '14 at 13:46
  • Yes, mkdir $BACKUP_MNTPOINT/$USER_HOME/foo creates a directory with the user's ownership. – kralyk Nov 1 '14 at 13:50
  • Would be really nice to see relevant information from strace (as specified in a pseudo answer). – Pavel Šimerda Dec 22 '14 at 19:36

I had a similar problem when using rsync to backup my system to my server. I used:

rsync -aAXSHPr \
-e ssh \
--rsync-path="sudo /usr/bin/rsync/" \
--numeric-ids \
--delete \
--progress \
--exclude-from="/path/to/file/that/lists/excluded/folders.txt" \
--include-from="/path/to/file/that/lists/included/folders.txt" \
/ USER@SERVER:/path/to/folder/where/backup/should/go/

The solution is that there is not really a problem. I suspect that you aborted the rsync process once you saw that it creates folders with wrong permissions set. The crux is that rsync only sets the permissions of a parent-folder once it is done syncing all subfolders and files of it.

  • 1
    Wow, that didn't occur to me at all, nicely spotted, thanks. – kralyk Mar 25 '15 at 17:39

Perhaps run rsync via strace/truss and see if you get an error back from the chown() syscall, and also to confirm that chown() has the correct path and UID/GID.

  • A good comment but not an answer. – Pavel Šimerda Dec 22 '14 at 19:35

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.