Hi all. I'm getting the following error when using rsync:
nice -n 20 rsync -e "ssh -p30000" --recursive --verbose --verbose
--checksum
--times --modify-window 2 --port=31000 --dry-run
/cygdrive/f/bkp/Doc/Builds/Buildsheets/ MYUSERNAME@MY.SERV.ER.IP:TESTDIR
opening connection using ssh -p30000 -l MYUSERNAME MY.SERV.ER.IP rsync
--server -vvntrc --modify-window=2 . TESTDIR
Debian GNU/%s 3.0 %h
MYUSERNAME@MYSERVERIP's password:
building file list ...
expand file_list to 4000 bytes, did move
done
created directory TESTDIR
rsync: push_dir TESTDIR: No such file or directory
rsync error: errors selecting input/output files, dirs (code 3) at
main.c(294)
rsync: read error: Connection reset by peer
rsync error: error in rsync protocol data stream (code 12) at io.c(162)
On the client I'm using Win2K SP2, running Cygwin's rsync 2.5.5 and
OpenSSH_3.4p1.
On the Linux Debian Woody server, I'm using rsync version 2.5.6cvs protocol
version 26, with ssh OpenSSH_3.4p1 Debian 1:3.4p1-1.
Because MYSERVER is behind a firewall which services multiple machines
providing ssh, I'm forwarding Internet-side ports 30000 and 31000 to ssh and
rsync, respectively, on MYSERVER. On MYSERVER, those daemons are listening
on their conventional port numbers. (Because I'm not sure at which point
the rsync data stream takes over, I've tried the command both with and
without the --port=31000 switch. No dice either way.)
Here's what MYSERVER's /etc/rsyncd.conf looks like:
log file = /var/log/rsyncd.log
[TESTDIR]
path = /home/MYUSERNAME/TESTDIR
read only = false
strict modes = false
uid = MYUSERNAME
gid = nogroup
auth users = MYUSERNAME
secrets file = /etc/rsyncd.secrets
transfer logging = yes
log format = [%m] %o %u@%h %f [length:%l tran:%b] (%a)
Daemian Mack
> Hi all. I'm getting the following error when using rsync: > > nice -n 20 rsync -e "ssh -p30000" --recursive --verbose > --verbose --checksum > --times --modify-window 2 --port=31000 --dry-run > /cygdrive/f/bkp/Doc/Builds/Buildsheets/ > MYUSERNAME@MY.SERV.ER.IP:TESTDIRIn case this helps clarify the issue for anyone, I *can* manually create an ssh tunnel from my Win2K workstation to the remote MYSERVER, and *then* rsync successfully over that tunnel: ssh -v -v -v -p3000 -L 873:127.0.0.1:873 MYUSERNAME@MYSERVER nice -n 20 rsync --recursive --verbose --verbose --checksum --times --modify-window 2 /cygdrive/f/bkp MYUSERNAME@MYSERVERIP:TESTDIR opening tcp connection to 127.0.0.1 port 873 Password: building file list ... expand file_list to 4000 bytes, did move So it's successful when rsync itself isn't initiating the ssh tunnel... I don't know what this means. Daemian Mack
tim.conway@philips.com
2002-Aug-27 12:03 UTC
rsync: push_dir TESTDIR: No such file or directory
Daemian: You're mixing two mutually-exclusive modes - rsync over ssh, and
rsync over rsync internal TCP transport to an rsyncd. -e ssh is ignored
on rsync to rsyncd, and rsync to rsyncd requires the
double-colon("::")
representation of the remote. The --port= is also relevant only to
contacting an rsyncd.
In this case, you are opening an ssh stream, and passing info over that,
to a shell. "MYUSERNAME@MY.SERV.ER.IP:TESTDIR" means external
transport to the subdirectory named "TESTDIR" under the
home directory of "MYUSERNAME" on machine "MY.SERV.ER.IP".
So, your rsyncd.conf is also meaningless in this context.
Looking at it from the purpose of successfully doing what your command
does, I'd first try
ssh MY.SERV.ER.IP <-l MYUSERNAME> pwd
and see if it's what you expect. You might be landing in a directory
where you don't have write perms... It's happenned.
Let me know what you find.
Tim Conway
tim.conway@philips.com
303.682.4917 office, 303.921.0301 cell
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, caesupport2 on AIM
"There are some who call me.... Tim?"
"Mack, Daemian" <DMack@Tickets.com>
Sent by: rsync-admin@lists.samba.org
08/27/2002 10:52 AM
To: rsync@lists.samba.org
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: rsync: push_dir TESTDIR: No such file or directory
Classification:
Hi all. I'm getting the following error when using rsync:
nice -n 20 rsync -e "ssh -p30000" --recursive --verbose --verbose
--checksum
--times --modify-window 2 --port=31000 --dry-run
/cygdrive/f/bkp/Doc/Builds/Buildsheets/ MYUSERNAME@MY.SERV.ER.IP:TESTDIR
opening connection using ssh -p30000 -l MYUSERNAME MY.SERV.ER.IP rsync
--server -vvntrc --modify-window=2 . TESTDIR
Debian GNU/%s 3.0 %h
MYUSERNAME@MYSERVERIP's password:
building file list ...
expand file_list to 4000 bytes, did move
done
created directory TESTDIR
rsync: push_dir TESTDIR: No such file or directory
rsync error: errors selecting input/output files, dirs (code 3) at
main.c(294)
rsync: read error: Connection reset by peer
rsync error: error in rsync protocol data stream (code 12) at io.c(162)
On the client I'm using Win2K SP2, running Cygwin's rsync 2.5.5 and
OpenSSH_3.4p1.
On the Linux Debian Woody server, I'm using rsync version 2.5.6cvs
protocol
version 26, with ssh OpenSSH_3.4p1 Debian 1:3.4p1-1.
Because MYSERVER is behind a firewall which services multiple machines
providing ssh, I'm forwarding Internet-side ports 30000 and 31000 to ssh
and
rsync, respectively, on MYSERVER. On MYSERVER, those daemons are
listening
on their conventional port numbers. (Because I'm not sure at which point
the rsync data stream takes over, I've tried the command both with and
without the --port=31000 switch. No dice either way.)
Here's what MYSERVER's /etc/rsyncd.conf looks like:
log file = /var/log/rsyncd.log
[TESTDIR]
path = /home/MYUSERNAME/TESTDIR
read only = false
strict modes = false
uid = MYUSERNAME
gid = nogroup
auth users = MYUSERNAME
secrets file = /etc/rsyncd.secrets
transfer logging = yes
log format = [%m] %o %u@%h %f [length:%l tran:%b] (%a)
Daemian Mack
--
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
> Daemian: You're mixing two mutually-exclusive modes - rsync > over ssh, and > rsync over rsync internal TCP transport to an rsyncd. -e ssh > is ignored > on rsync to rsyncd, and rsync to rsyncd requires the > double-colon("::") > representation of the remote. The --port= is also relevant only to > contacting an rsyncd. > In this case, you are opening an ssh stream, and passing info > over that, > to a shell. "MYUSERNAME@MY.SERV.ER.IP:TESTDIR" means > external transport to the subdirectory named "TESTDIR" under the > home directory of "MYUSERNAME" on machine "MY.SERV.ER.IP".I'm confused. I *am* using the single-colon, which, according to the man page, is the right way to specify "I want to use SSH for this operation," which I do.> So, your rsyncd.conf is also meaningless in this context.I'm starting to suspect that I can rsync to a machine that literally *does not have* rsync running in any sort of daemon capacity. Is this accurate?> Looking at it from the purpose of successfully doing what > your command > does, I'd first try > ssh MY.SERV.ER.IP <-l MYUSERNAME> pwd > and see if it's what you expect. You might be landing in a directory > where you don't have write perms... It's happenned.I have tried this, and am landing right where I expect to, in my remote home directory. The directory I'm specifying to sync with is present and is me-writable. In any case, it's working today. The only change I've made is to reboot the rsync server for an unrelated issue. I don't know what changed to make it start working, but at least it is. ;) Thanks for the pointers! Daemian Mack
tim.conway@philips.com
2002-Aug-30 04:39 UTC
rsync: push_dir TESTDIR: No such file or directory
I'm glad it's working. I wonder what was going on on the destination
that
could be fixed with a reboot... but on a production environment, sometimes
root cause analysis is a luxury you just can't afford.
I agree. You *are* using the single-colon syntax, but you've also brought
up your rsyncd.conf, and are using the -p option. Maybe rsync should have
complained about the wrong options, rather than just going ahead and
working. There has been some discussion about having rsync refuse to run,
rather than just silently ignoring meaningless options. It's low priority
work, though.
Yes, you CAN rsync to a system that isn't running an rsync daemon. In
fact, that is the most common mode. As the maintainers explain:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Once installed you can use rsync to any machine that you can
use rsh to. rsync uses rsh for its communications, unless
both the source and destination are local.
You can also specify an alternative to rsh, either by using
the -e command line option, or by setting the RSYNC_RSH
environment variable.
One common substitute is to use ssh, which offers a high
degree of security.
SunOS 5.7 Last change: 25 Jan 2002 2
User Commands rsync(1)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Some have used ssh to set up port forwarding to the rsyncd, so that the
restrictions on the remote end rsyncd can be used inside the ssh
transport, but that's external stuff, not part of the actual program.
Tim Conway
tim.conway@philips.com
303.682.4917 office, 303.921.0301 cell
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, caesupport2 on AIM
"There are some who call me.... Tim?"
"Mack, Daemian" <DMack@Tickets.com>
Sent by: rsync-admin@lists.samba.org
08/29/2002 12:03 PM
To: Tim Conway/LMT/SC/PHILIPS@AMEC
"Mack, Daemian" <DMack@Tickets.com>
cc: rsync@lists.samba.org
Subject: RE: rsync: push_dir TESTDIR: No such file or directory
Classification:
> Daemian: You're mixing two mutually-exclusive modes - rsync
> over ssh, and
> rsync over rsync internal TCP transport to an rsyncd. -e ssh
> is ignored
> on rsync to rsyncd, and rsync to rsyncd requires the
> double-colon("::")
> representation of the remote. The --port= is also relevant only to
> contacting an rsyncd.
> In this case, you are opening an ssh stream, and passing info
> over that,
> to a shell. "MYUSERNAME@MY.SERV.ER.IP:TESTDIR" means
> external transport to the subdirectory named "TESTDIR" under the
> home directory of "MYUSERNAME" on machine
"MY.SERV.ER.IP".
I'm confused. I *am* using the single-colon, which, according to the man
page, is the right way to specify "I want to use SSH for this
operation,"
which I do.
> So, your rsyncd.conf is also meaningless in this context.
I'm starting to suspect that I can rsync to a machine that literally *does
not have* rsync running in any sort of daemon capacity. Is this accurate?
> Looking at it from the purpose of successfully doing what
> your command
> does, I'd first try
> ssh MY.SERV.ER.IP <-l MYUSERNAME> pwd
> and see if it's what you expect. You might be landing in a directory
> where you don't have write perms... It's happenned.
I have tried this, and am landing right where I expect to, in my remote
home
directory. The directory I'm specifying to sync with is present and is
me-writable.
In any case, it's working today. The only change I've made is to reboot
the
rsync server for an unrelated issue. I don't know what changed to make it
start working, but at least it is. ;) Thanks for the pointers!
Daemian Mack
--
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
> I'm glad it's working. I wonder what was going on on the > destination that > could be fixed with a reboot... but on a production > environment, sometimes > root cause analysis is a luxury you just can't afford.Too true. Luckily, this is my own home machine, so I can do all the poking I need to.> I agree. You *are* using the single-colon syntax, but you've > also brought > up your rsyncd.conf, and are using the -p option. Maybe-p? I'm not using it explicitly, but I know certain rsync options are aliases for other ones, so... For the record, here's the command I'm using again: nice -n 20 rsync -e "ssh -p3000" --recursive --verbose --verbose --checksum --times --modify-window 2 /cygdrive/f/bkp MYUSERNAME@MY.SERV.ER.IP:TESTDIR> rsync should have > complained about the wrong options, rather than just going ahead and > working. There has been some discussion about having rsync > refuse to run, > rather than just silently ignoring meaningless options. It's > low priority > work, though.As a sometimes-developer, my own (humble) two cents is that having rsync fail verbosely when passed inappropriate arguments is a very good idea.> Yes, you CAN rsync to a system that isn't running an rsync > daemon. In fact, that is the most common mode.Cool. rsync always happily surprises me. Daemian Mack