Hi,
Carlos Carvalho wrote:
Jon Watson (jwat...@watsysgroup.com) wrote on 14 July 2009 19:15:
>Carlos Carvalho wrote:
>> Jon Watson (jwat...@watsysgroup.com) wrote on 14 July 2009 17:17:
>> >I am using rsync to backup one server to another. I am connecting to the
>> >rsync daemon on the remote server and pulling to the backup server. When
>> >using SSH this error does not occur, but there are reasons why I have to
>> >use rsync directly.
>>
>> >The problem I am having is that some of the symlinks on the remote
>> >machine will not copy. I am attempting to copy their referent by using
>> >the -L option, but I always receive the subject error despite the fact
>> >that the referent does actually exist.
>>
>> >My rsyncd.conf file has uid = root and gid = nobody for this path.
>>
>> Even though the daemon runs as root, there may have been a chroot
>> before. In other words, the process that is launched by ssh may not
>> have the same view of the filesystem that the one coming from the
>> rsync daemon.
>
>The /etc/xinetd.d/conf file is the file that determines what user the
>daemon runs under (on my system, anyhow). It specifies that the daemon
>should run as root.
>
>However, just because the daemon is running as root doesn't mean the
>individual copy commands are run as root. It is the uid=root in the
>module configuration in the /etc/rsyncd.conf file that specifies what
>user the individual copies should be performed as. Thus, my copies are
>being performed as root.
As I said, it doesn't seem to be a question of uid, it's a filesystem
view. A chroot affects root as well.
>> You might be able to do an experiment launching a daemon directly from
>> the command line as root listening in another port and see if this
>> instance finds the referent.
>
>I've done this test during my mucking around, but didn't mention it. If
>I start rsync as root with the --daemon option on the remote server, I
>get the same error messages.
From the manual:
use chroot
If “use chroot” is true, the rsync daemon will chroot to the
“path” before starting the file transfer with the client. This
has the advantage of extra protection against possible implemen‐
tation security holes, but it has the disadvantages of requiring
super-user privileges, of not being able to follow symbolic
links that are either absolute or outside of the new root path,
and later:
hierarchy. The default for “use chroot” is true, and is the
safer choice (especially if the module is not read-only).
This feature is activated if you run rsync in daemon mode, which seems
to agree with your results.
That was it, thanks.
Interestingly enough, the version of rsync on the backup server supports
use chroot, but there is no mention of it in the man pages that I found.
Much appreciated.
Jon
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
