similar to: documentation bug for --daemon "use chroot" in conjunction with -o and -g

I am using rsync 2.5.5 running as a daemon on the destination system, which is SuSE Linux 8.0. The source system is SuSE 7.3, also with rsync 2.5.5. With the default 'use chroot = true' and not using --numeric-ids, I get the wrong user names on the destination files. I have tracked this down to getpwnam() failing to return the user name from the passwd file. It does not fail when

The following is a patch I've been working on to support a "ChrootUser" option in the sshd_config file. I was looking for a way to offer sftp access and at the same time restict interactive shell access. This patch is a necessary first step (IMO). It applies clean with 'patch -l'. Also attached is a shell script that helps to build a chrooted home dir on a RedHat 7.2

Hello, I am trying to run rsync under my own userid on a high-numbered port. The problem is that, when I use the --daemon option, I get an error saying that a chroot() call failed. My config file does *not* have any chroot call in it. How can I avoid a chroot() invocation when running as a normal non-root user? Thanks in advance for any advice! -- Daniel Ortmann, LSI Logic, 3425 40th Av NW,

Hello all, I've found some behavior in 2.5.5 that is contrary to the documentation in the man page. Specifically, I'm running an rsync server (i.e. from inetd with --daemon),and in the module definition I'm specifying the line "exclude nosyncdir". The documentation for rsyncd.conf indicates that this is exactly equivalent to using "--exclude nosyncdir" on the

At the moment, if you start an rsyncd that's not running as root using default settings it will have some trouble. rsyncd tries to use chroot by default, but this will always fail if it's not started by root. It does emit an error message in this case, but I wonder if some people find this a bit confusing until they discover the setting. I have in the past. It might be better that if

And, I've found more. It turns out that even though the exclude directive is ignored for inbound data in rsyncd.conf, it is NOT ignored for the --delete option. I've seen this behavior occur when I've deleted a file from the sending side (client) that is inside a tree that's matched by the server-side (rsyncd) exclude directive. The deletion is ignored, as the documenation

Why would I be getting this on a box? I have the same permissions on many other directories. Using verbose mode shows nothing more then the error in the Subject line. Any help is appreciated. -- Jason G Helfman Network Administrator BizRate.com 310.754.1264 desk

https://bugzilla.samba.org/show_bug.cgi?id=11013 Bug ID: 11013 Summary: [patch] Mention that privileges are dropped, when "use chroot" is enabled in rsyncd.conf manpage Product: rsync Version: 3.1.1 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5

I'm trying to synchronize a particularly troublesome directory structure on a SunOS box to a PC. I really want all symbolic links resolved to real files on the PC when everything is done. I can't seem to find any combination of parameters that will accomplish this. It boils down to two problems. 1. It seems like that even if I exclude a symbolic link that is a directory it is not

I have rsync-2.5.5 humming along on FreeBSD 4.7-STABLE with no apparent problems. However, I notice when some clients connect to sync, I get this in /var/log/messages rsyncd[42843]: /etc/pwd.db: No such file or directory rsync is running as root with this basic rsync.conf: use chroot = yes read only = yes timeout = 600 Well of course /etc/pwd.db exists and could be readable, but more

The subject says it all :-) Apparently in pre-3.0.0 versions '%P' would log the actual path as specified in the module entry in rsyncd.conf, but now it's apparently relative to the chroot... Paul Slootman

Greetings, Has anyone successfully compiled rsync 2.5.5 under Mac OS X (not Server), and actually have it work fully? I'm in a position where I'm trying to setup an automated nightly remote backup between and Cobalt Raq4 (running a variant of Redhat Linux) and a Mac running OS X 10.1.5 with the latest development tools installed. As has been pointed out previously on the list, one has

Hi all: I tried to start a rsync daemon under my user name (not an administrator) on debian linux box(linux kernel 2.4.27), and failed. The command I used is > rsync -v -v --daemon --config=rsyncd.conf This command returns without any error although the daemon does not get started. The rsyncd.conf I used is as follows. Do I miss anything in the configuration file? Any help is appreciated.

Hello. I running rsync in daemon mode (rsync --daemon) Everything seems to work well until I try to protect item with password. here is my /etc/rsyncd.conf : use chroot = yes max connections = 10 syslog facility = local5 [ftp] path = /var/ftp comment = ftp secrets file = /etc/rsyncd.secrets auth users = gate1 here is my /etc/rsyncd.secrets gate1:abcdefg Here

I am trying to use rsync to transfer some directories from a RedHat 7.0 box to a RedHat 7.1 rsync server via a cron job. The cron command line: 00 00 * * * /usr/local/bin/emailbackup > /tmp/backup.log 2>&1; mail -s "Rsync Backup Log" my@emailaddres < /tmp/backup.log The 7.1 rsyncd.cond; [home] path = /home/brad/data/emailbackup read only = no uid = root gid = root The

This has been asked before, but my question is somewhat different. On FreeBSD, the message: rsyncd[520]: /etc/pwd.db: No such file or directory is obviously caused by a chrooted rsyncd being unable to access /etc/pwd.db to get at the password database to convert UIDs to names and back. Workorounds of putting /etc/pwd.db in the chrooted directory have been offered, and that's one solution.

Hello, I am trying to configure rsyncd to mount destination encrypted FS (using EncFS) before syncing. In my rsyncd.conf : [test] path = /home/dest <...> pre-xfer exec = sleep 30 ; echo mypassword | encfs -S /home/ encrypteddir /home/dest ; sleep 30 (I have put "sleep 30" instructions just to make some tests) /home/encrypteddir is correctly mounted by rsyncd to /home/dest

https://bugzilla.samba.org/show_bug.cgi?id=10772 Summary: Bad time logging as daemon Product: rsync Version: 3.1.1 Platform: x64 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: davegradwell at yahoo.co.uk

Took a while to figure this one out: Since "use chroot" defaults to true, I was having issues of UID/GID's not mapping between servers. On AIX, if chroot() is called, the getpwuid() calls fail, no longer being able to find /etc/passwd. Since the that call doesn't differentiate between a 'failure' and a 'unable to map uid', rsync assumes it can't map the

Hi, I am not sure it this still is a point, but I just discovered that a chrooted rsync version 2.6.3pre1 is forgetting the time zone underways: Jan 12 07:00:01 ftp4 rsyncd[11091]: rsync on dobes/ from dobes@edoc1.gwdg.de (134.76.28.251) Jan 12 06:00:39 ftp4 rsyncd[11091]: wrote 732542 bytes read 182 bytes total size 553909487945 Logging is done with syslog. Time zone is GMT+1, the system