14

I am quite confused as to why rsync requires --rsync-path flag even when remote rsync is in path.

Consider:

$ rsync -avze 'ssh -p 22' --delete public/ pmatos@domain.com:~/public_html
bash: /usr/local/bin/rsync: No such file or directory
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: remote command not found (code 127) at io.c(601) [sender=3.0.7]

then I tried adding --rsync-path

$ rsync -avze 'ssh -p 22' --rsync-path=/usr/bin/rsync  --delete public/ pmatos@domain.com:~/public_html
sending incremental file list
...

So, the first rsync was not successful because it was searching for rsync in /usr/local/bin but as soon as I pass the obvious path for rsync using --rsync-path, then it works.

Why is this? (this command line is the one issued by rake deploy in octopress)

Paulo Matos
  • 309
  • 2
  • 3
  • 10

2 Answers2

3

My memory is now quite fuzzy on this but the reason this was happening was that I used GNU stow on rsync at some point and created some symlinks that confused rsyncs location. This was sorted after much hair-pulling. I am now much lighter on hair but on the other hand I have a working rsync. That must be a win if you ask me.

Paulo Matos
  • 309
  • 2
  • 3
  • 10
0

rsync connects to remote sshd which is usually compiled with a static PATH (check comments on sshd_config file).

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

Probably your rsync is not in that path.

This is the PATH used when running a remote command and is different than the PATH environment you might get from dotfiles when running an interactive ssh remote login shell.

You can check this by running:

ssh <remote-host> 'echo $PATH'

and comparing that to what you get when you do:

ssh <remote-host>

prompt on remote host


> echo $PATH
mattpr
  • 778