On 06/08/2009 11:26:01 AM, H.S. wrote:
Hello,I have a Debian box (running Testing) which rsyncs some directories from a Windows laptop (running XP on an ntfs partition) to a partition on a local disk on the Debian box. The Debian box uses rsync via ssh connection made with the XP box which has cygwin and ssh server installed. The user used to do the ssh connection is an administrator on the XP box ('root'). The script is running from the root account on the Debian box. The command is something like this: rsync --delete --modify-window=10 --force -Rvaue ssh --exclude-from=$EXCLUDESFILE --progress \ xp-box:"/cygdrive/c/Documents\ and\ Settings/user1 /cygdrive/c/Documents\ and\ Settings/user2" /mnt/backups/xp-daily-00; where $EXCLUDESFILE is a variable defined with the path to the excludes files on the Debian box. Now, this all works very well for making the backups. However, the permissions of the files pulled from the XP box to the Debian box are the same as on the XP box. The same two users, user1 and user2, also exist on the Debian box. However, the gids and uids of these users are different on the XP box and on the Debian box. So the users cannot browse their own directories (backups) from within the Debian box (permissions denied). This is a problem if a user wants to browse, or recover files from, his backups by connecting from the XP box to the Debian box using ssh (because then the user's gid and uid are Debian numbers, not the XP, or cygwin on XP, numbers). Any ideas how I get around this problem?
a) Don't do that. Have the uid/gids be the same on the MS and Debian sides. b) Use --numeric-ids in the rsync script and after it finishes use find -uid and chown to change the uids to the "right" value. (Likewise for gids.) c) Have the users recover/browse their backups with samba instead of ssh and have samba map the uids/gids "properly". Karl <[email protected]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
