14

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.

Improve this question
6
  • 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 ♦
    Commented Nov 1, 2014 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
    Commented Nov 1, 2014 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 ♦
    Commented Nov 1, 2014 at 13:46
  • Yes, mkdir $BACKUP_MNTPOINT/$USER_HOME/foo creates a directory with the user's ownership.
    – kralyk
    Commented Nov 1, 2014 at 13:50
  • Would be really nice to see relevant information from strace (as specified in a pseudo answer).
    – Pavel Šimerda
    Commented Dec 22, 2014 at 19:36

2 Answers 2

Reset to default
24

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.

Improve this answer
3
  • 1
    Wow, that didn't occur to me at all, nicely spotted, thanks.
    – kralyk
    Commented Mar 25, 2015 at 17:39
  • rsync-path would be "sudo /usr/bin/rsync" rather than "sudo /usr/bin/rsync/", right?
    – Fumisky Wells
    Commented Jul 12, 2020 at 1:06
  • Also rsync needs to be run as root in order to preserve ownership.
    – Afanasii Kurakin
    Commented Aug 6, 2022 at 6:18
0

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.

Improve this answer
1
  • 1
    A good comment but not an answer.
    – Pavel Šimerda
    Commented Dec 22, 2014 at 19:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .