Hi all, Tripped over a documentation bug. I'm guessing the behavior I've found isn't a bug in itself as it's kind of implied by chroot (unless the /etc/passwd db is read *before* you do the chroot call), so I'm calling it a documentation bug.
The Setup: System A: running rsync --daemon from xinetd, configured with a read-only share. System B: syncing a local directory structure from the share on System A. Both running Red Hat Linux 7.2, and rsync 2.5.4 The Problem: The documentation indicates that -o and -g on the client side preserve the user and group of the files/dirs transferred as compared by name (i.e. for sync A=>B, if the uid for "bob" is 205 on A, and 3328 on B, then the uid of the file will be converted transparently to 3328 on B during a sync). HOWEVER, what isn't mentioned in the man page for either rsync or rsyncd.conf is that for the -o and -g options to work, the server side MUST have "use chroot = no" in the config file. As the default behavior for rsync is "use chroot = yes", this can make things frustrating when the directions and the behavior don't quite sync (pun gleefully intended) up. It ends up setting the uid and gid to the numeric ids from the server side, which is functionally equivalent to using --numeric-ids (with variations based on what user the client side is running as). The Solution: Mention on the rsync man page in the -o and -g descriptions that syncing from a --daemon based share requires that "use chroot = no" be specified in the rsyncd.conf, and mention on the rsyncd.conf man page that if "use chroot = no" isn't specified in the rsyncd.conf that -o and -g will not work on the client side. Thanks for your attention, Scott -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
