How to Fix “rsync error: remote command not found (code 127)” When Using SSH Remote Sync


4 views

While performing a routine server synchronization using rsync over SSH, I encountered this frustrating error:

bash: 192.168.0.1: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: remote command not found (code 127) at io.c(605) [Receiver=3.0.9]

My first approach was to simplify the complex command that included nested ionice and nice priorities:

sudo ionice -c 3 nice -n +19 rsync -av --progress -e 'ionice -c 3 nice -n +19 ssh -l root -p 22 192.168.0.1' 192.168.0.1:/domains/remote/. /domains/local/;

Stripping it down to basic rsync over SSH:

rsync -av --progress -e 'ssh -l root -p 22 192.168.0.1' 192.168.0.1:/domains/remote/. /domains/local/;

The error occurs because rsync is incorrectly interpreting the remote host specification. When you include the IP address both in the -e parameter and as the remote host, the SSH command gets malformed.

The correct syntax removes the IP address from the -e parameter:

rsync -av --progress -e 'ssh -l root -p 22' 192.168.0.1:/domains/remote/. /domains/local/;

For better readability, you can also use these equivalent formats:

rsync -av --progress -e "ssh -p 22" root@192.168.0.1:/domains/remote/. /domains/local/

# Or using SSH config aliases
rsync -av --progress /domains/remote/. remote-server:/domains/local/

If you still encounter issues, try these debugging steps:

# Add verbose flags to SSH
rsync -av --progress -e 'ssh -vvv -l root -p 22' 192.168.0.1:/domains/remote/. /domains/local/

# Test SSH connection separately
ssh -l root -p 22 192.168.0.1 "which rsync"

# Check remote rsync version
ssh root@192.168.0.1 "rsync --version"

For different authentication methods:

# Using SSH key authentication
rsync -av --progress -e 'ssh -i /path/to/private_key' user@host:/remote/path/ /local/path/

# Custom SSH port
rsync -av --progress -e 'ssh -p 2222' user@host:/remote/path/ /local/path/

Yesterday, your rsync commands worked flawlessly. Today, you're greeted with this frustrating error:

bash: 192.168.0.1: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: remote command not found (code 127) at io.c(605) [Receiver=3.0.9]

This is a classic case where the remote server can't properly interpret your rsync command due to SSH syntax issues. Let's break down why this happens and how to permanently fix it.

The original problematic command contained:

rsync -av --progress -e 'ssh -l root -p 22 192.168.0.1' 192.168.0.1:/domains/remote/. /domains/local/

The key issue lies in the -e (remote shell) parameter. The hostname appears twice - both in the SSH command and as part of the rsync destination. This duplication confuses the remote shell interpreter.

After several iterations, the working version emerges:

rsync -av --progress -e 'ssh -l root -p 22' 192.168.0.1:/domains/remote/. /domains/local/

Notice how we removed the hostname from the SSH command portion while keeping it in the rsync destination path. This maintains all the intended functionality while avoiding the interpretation error.

For different authentication and connection scenarios, these formats also work reliably:

# Using SSH config aliases
rsync -av --progress -e 'ssh -F ~/.ssh/config' backup-server:/data/ ./local_backup/

# With identity file
rsync -av --progress -e 'ssh -i ~/.ssh/id_rsa_backup' user@remote:/path/ ./local/

# Different port without username
rsync -av --progress -e 'ssh -p 2222' remote:/files/ ./local_files/

The 127 error specifically means the remote shell couldn't find/execute the command you requested. When you include the hostname in the SSH command portion, the remote server tries to execute that hostname as if it were a command (hence "command not found").

The rsync protocol establishes two connections:

  1. The SSH transport layer connection
  2. The actual rsync data transfer

Mixing up these components leads to the confusing error we encountered.

If you're still encountering issues after fixing the SSH syntax, try these diagnostic steps:

# Test SSH connection separately
ssh -l root -p 22 192.168.0.1 "which rsync"

# Verify remote rsync path
rsync -av --rsync-path="/usr/bin/rsync" -e ssh user@host:/source/ /dest/

# Enable verbose output for debugging
rsync -avvv --progress -e 'ssh -v' remote:/path/ local/

The -vvv flag provides maximum verbosity, while --rsync-path explicitly specifies the remote rsync binary location.

For production environments, consider these reliability improvements:

# Use SSH ControlMaster for multiple transfers
rsync -av --progress -e 'ssh -o ControlMaster=auto -o ControlPersist=60' host:/src/ /dst/

# Add connection timeout parameters
rsync -av --progress --timeout=30 -e 'ssh -o ConnectTimeout=10' host:/src/ /dst/

# Automate with SSH keys and keepalives
rsync -av --progress -e 'ssh -o ServerAliveInterval=60' host:/src/ /dst/

These additions make your rsync operations more resilient to network fluctuations and authentication issues.