Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

When both source and destination are remote, rsync complains:

The source and destination cannot both be remote. rsync error: syntax or usage error (code 1) at main.c(1156) [Receiver=3.0.7]

Is there a insurmountable technical obstacle to making rsync do this? Or it's simply a case of it's-not-yet-implemented? It seems relatively easy to create a local buffer in memory that mediates the transfer between two remotes, holding both hashes and data.


Since people are making some tangent suggestions, I've posted a separate question about my particular use case. These are two separate, really, and I think it'd be worthwhile to know these particular details for rsync

share|improve this question

closed as not constructive by Michael Hampton, Magellan, Bryan, MadHatter, Chris S Nov 20 '12 at 15:17

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

It would involve a remote src rsyncd sending data to a remote dest rsyncd. You can work around it by ssh'ing to the src system and invoking rsync. –  Alex Holst Nov 17 '12 at 14:18
@AlexHolst I don't think that would work in my particular case. see edit –  goncalopp Nov 18 '12 at 1:35
Sorry, Server Fault doesn't deal with theoretical questions; only Answerable questions about problems you actually face. See the FAQ for more details. –  Chris S Nov 20 '12 at 15:17

3 Answers 3

why not try and connect to the remote machine and start the transfer from there. If you are using ssh-keys you can use agent pass though to manage the authenticate for you.

ssh -A remotehostA rsync /remote/file/on/host/a remoteHostB:/destination/

This command will log you on the remoteHostA and run rsync from there.

share|improve this answer
There's some security considerations involved. See edit –  goncalopp Nov 18 '12 at 1:38
Also, that won't work if you don't have direct access between the two systems... And if getting direct access involves waiting two weeks for a security section to maybe correctly implement firewall rules... –  Gert van den Berg Nov 25 '14 at 12:38

scp <remote src> <remote dest> has no trouble doing this.

share|improve this answer
scp doesn't do deltas though, AFAIK, and it's badly needed in this case. More details on my edit –  goncalopp Nov 18 '12 at 1:42
Btw, scp have to be with options -3 if you'd like to be like a proxy between hosts –  alterpub Dec 3 '14 at 15:18

You can work around this by mounting one (or both) of the remote filesystems with sshfs. Then, rsync will treat it as if it were local.

Unfortunately, this will result in a lot of bandwidth usage on the machine whose filesystem is mounted with sshfs, so I would recommend only doing this with the machine that has a lot of bandwidth between you and the third machine.

Of course, the ideal solution is for the machines to talk directly to each other. I can't think of any good reason why they should not.

share|improve this answer
see edit. The reason you're referring to is security. A (root) compromise any one of the two machines must not lead to filesystem access to the other. But maybe I'm attacking this from the wrong angle and there's a solution that doesn't involve a third machine... –  goncalopp Nov 18 '12 at 1:41
Hmm. I think those details really should be added to this question. As for a root compromise, you really should be using SELinux. –  Michael Hampton Nov 18 '12 at 1:47
I left this one because someone else may be interested in this behaviour on rsync in particular. AFAIK, SELinux on any of the machines cannot tell if the other has been compromised if the locally executing rsync has the exact same behaviour in both cases (filesystem access to a particular directory). –  goncalopp Nov 18 '12 at 1:52
I'm not sure if you understand how SELinux works. Its whole point is that it prevents a service (even a compromised service) from accessing things it isn't explicitly allowed to access, even if that service runs as root. –  Michael Hampton Nov 18 '12 at 1:59
I have only a basic understanding of SELinux policies, but rsync is supposed to access the filesystem, isn't it? The exact same kind of (local) access patterns are undesirable if the remote machine is compromised. –  goncalopp Nov 18 '12 at 2:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.