rsync - Jun 2011 - rsync 3.0.6 and keep-dirlinks in daemon mode

Hello,

I'm trying to push some data from one machine to another via rsync
source machine uses rsync 3.0.8, it's a CentOS 5.6 Linux with rsync 3.0.8
package from rpmforge
destination machine uses rsync 3.0.6, it's a Scientific Linux 6.0 with rsync
3.0.6 from its repository

destination machine is running a rsync daemon with the following configuration:
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT
[data1]
        path = /data1
        comment = data1
        read only = false
        uid = ouruser
        gid = ourgrp
        hosts allow = 10.2.1.188
        timeout = 300

and from source machine I'm pushing some data like:
rsync -av --keep-dirlinks /data/hudson/ 10.2.2.74::data1

it works fine except for the --keep-dirlinks option which doesn't have any
effect, so symlinks at the target machine as simply overwritten as if there was
no --keep-dirlinks option at all

But when I try the same in shell mode, like:
rsync -av --keep-dirlinks /data/hudson/ 10.2.2.74:/data1

it keeps the symlinks at target location as expected. 
Is there a way to achieve the same behavior against the rsync daemon? Or what am
I doing wrong?

Thank you,
Peter

On Tue, Jun 28, 2011 at 3:38 AM, <hostalp at post.cz> wrote:
> Is there a way to achieve the same [--keep-dirlinks] behavior against the
> rsync daemon?
>
I'd imagine that the symlinks aren't valid inside the "/data1"
chroot.  If
you can make the symlinks relative inside the /data1 hierarchy, you should
do that.  If not, you'll need to disable "use chroot", but you
must trust
your writing users enough if you do that (the "munge symlinks" option
will
be set by default w/o a chroot, which helps).

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20110628/faa14524/attachment.html>

Oh yeah, I completely missed that use chroot is enabled by default - that was
the cause as the particular link pointed completely elsewhere.
Thanks for the suggestion.

Petr