If you include the username and hostname in both the source and destination path, the rsync command fails. Example: 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 work.
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 moment.
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).