documentation bug for --daemon "use chroot" in conjunction with -o
pyxl at jerrell.com
Mon Jun 24 09:07:03 EST 2002
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.
System A: running rsync --daemon from xinetd, configured with a
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 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).
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,
More information about the rsync