If you include the username and hostname in both the source and destination path, the rsync command
rsync --progress -av username@host01:/root/path/file.ext username@host02:/root/path/file.ext
Results in error message:
mkstemp "/root/path/username@host02:/root/path/.file.ext.bEpHF5" failed: No such file or directory
It would appear that the path given to "mkstemp" is corrupted and cannot work.
One has to login to one of the two hosts and change the rsync command syntax to get the copy to
As mentioned in the manpage, rsync does not support a remote-to-remote copy.
Rsync currently treats the second of the args as a local filename that just
happens to have a colon in it. Rsync should probably be improved to notice that
the second spec appears to be a host-spec and reject it, but it does not at the
Created attachment 1314 [details]
Reject both source and destination specifying a host
Here's a patch to make rsync reject the case when both the source and
destination are remote.
I had meant to include some suggestions for remote-to-remote copying but forgot.
Let's remedy that.
Let's say you wish to be able to run "rsync -av host1:file host2:" from host3.
You could do one of two things:
ssh host1 rsync -av file host2:
That logs into host1 and does a copy of a local file to host2 directly, which
works if you can ssh from host1 to host2. Alternately, if you must use host3 as
a bridge between host1 and host2, do this:
ssh host1 rsync -av --rsync-path="ssh host2 rsync" file host3:
That logs into host1 and does a copy of a local file seemingly to host3 (that's
the host where it connects), but we told host3 to run the rsync command remotely
on host2, so the file is really being sent to host2 through host3. This only
works if you've configured ssh to allow logins without prompting for a password,
which is possible if you've setup some signed keys and you allow the forwarding
of ssh-agent (or if you've setup some kind of host-based authentication).