Rsync error protocol incompatibility code 2

Rsync error protocol incompatibility – Different causes and fixes

The rsync error protocol incompatibility occurs while transferring data using rsync to a remote server which has a .bashrc file.

Here at Bobcares, we have seen several such rsync command related errors as part of our Server Management Services for web hosts and online service providers.

Today we’ll take a look at the causes for this error and see the fix.

Different causes and fixes for ‘rsync error protocol incompatibility’

Now let’s see the different causes for this error to occur and fixes provided by our Support Engineers for it.

1. .bashrc outputting anything

Cause: Sometimes, if the .bashrc on the remote server output anything to the terminal then you may run into problems. Since rsync won’t expect this, it may also run into problems.

In order to check if it is the case, run the below command.

Where you would need to update the ‘remoteuser‘ with the username and IP-address with your IP address.

If the above command returns more than 0 then it means that there is some output being produced.

Solution: In order to resolve this issue, remove any commands in the .bashrc that output text, or you can try piping any output to /dev/null.

Manually, log in to this machine and look if you get any such message. Because for the rsync to work, you should get the remote command prompt. In case, if you receive a message, then try to disable it. Look at your shell config files (e.g.

/.bashrc, /etc/bash.bashrc for the bash shell) if they contain any command producing this output.

2. Difference in version

Cause: If there is any difference in rsync version between source and destination servers

Solution: You can simply upgrade the rsync version so that both the source and destination servers have the same rsync version.

3. Access restriction for a user

Cause: If there is restricted access for a user to SFTP only and is jailed to his home directory

Solution: To fix this problem, undo the restriction to SFTP in sshd_config. Or create a directory inside the directory user2 jailed/bind to. This directory is owned by user1, and hence able to rsync files into it.

The process will be as below: user2 was jailed / chrooted using

The directory was bind to his home directory by using:

After that, inside /var/ftp/ execute the below command:

After the files sync to that directory, they automatically appear in the user2 jail directory and the user can read them.

[Need any further assistance in fixing rsync errors? – We are here to help you.]

Conclusion

In short, the ‘rsync error protocol incompatibility’ occurs while transferring data using rsync to a remote server which has a .bashrc file. In today’s writeup, we saw the different causes and fixes our Support Engineers provide to our customers to fix this error.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

Источник

rsync errors — even rsync can go bananas!

rsync: [generator] symlink failed: Operation not supported (95)

Situation

I got this error while rsync ing data from a local filesystem to a network share served by Samba :

Details

This is not an rsync bug / limitation : rsync can’t create a symlink on a Samba share, and nobody could (at least, with current/default options ) : trying to create a symlink there manually would fail similarly.

Solution

rsync: failed to set permissions on » /path/to/someFile «: Operation not permitted

Situation

It’s all in the title :

• I’m trying to rsync data with the -a flag enabled (which implies -p)
• the user running rsync :
  • has rwx access permissions on :
    • /path/to/someFile : the file itself
    • /path/to/ : its parent directory

    which was granted via extended ACL

  • is not the owner of /path/to/someFile

Details

• To effectively preserve permissions (-p), rsync requires the same permission level as to run chmod (source).
• On the destination side of my rsync operation :
  • I can touch /path/to/someFile
  • I can’t chmod /path/to/someFile
• It turns out that some privileges are required to run chmod , which explains why it failed at the preceding step.

Solution

As a workaround , if you’re not interested in preserving file permissions, you can disable rsync ‘s -p with —no-perms.

skipping directory .

While experimenting / debugging rsync commands, you may end with very basic commands

• with / without the trailing slash / (doesn’t matter here)
• with no option

such as :

Error reading response length from authentication socket.

Situation

This message looks more like a warning than an actual error (?). Anyway, it seems to be related to a local ssh agent issue

Details

Could be caused by :

• local process(es ?) missing the result of eval $(ssh-agent)
• or concurrent ssh-agent processes :
  1. Check it with pgrep ssh-agent
  2. «kill -1» the extra processes

protocol version mismatch — is your shell clean?

Situation

Full error message :

Details

man rsync + searching for mismatch gives further information : while trying to rsync over SSH , it seems that the remote shell opening returns some unexpected data. To figure this out :

ssh bob @ remoteHost /bin/true

In normal situations, this should return nothing. Otherwise, the error message you’ll see is the reason why rsync fails.
For instance, when it said This account is currently not available, it’s because Bob had his shell set to /usr/sbin/nologin in /etc/passwd.

Solution

Changing Bob ‘s shell to /bin/sh fixed the issue.

Unexpected remote arg

The error has to do with how the nested double/single quotes are treated when the variables are expanded. Looks like rsync dislikes its arguments being quoted : rsync » —dry-run «

ksh: rsync: not found when trying to rsync files between a Linux and a Solaris machine

Situation

The complete error message is :

Details

This is caused by the PATH variable not having the same value on both ends of the connection.

Solution

/usr/local/bin/rsync is the path to the rsync binary on the Solaris machine.

Источник

Thread: rsync fails after upgrade to 14.04

Thread Tools

Display

rsync fails after upgrade to 14.04

After upgrading from 13.10 to 14.04 my rsync to a remote server is now
failing with message

protocol version mismatch — is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(62)
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]

This was coming from a cron job run daily on my local machine — it
worked successfully until the day after the upgrade. I also get the
same error when running a command-line rsync ala
rsync /home/user/DIR user@remotehost/DIR

Nothing on the remote machine’s rsync or ssh has been changed (nor has
anything else of any significance)

An on-line search says this is normally due to startup scripts or
remote shell facility producing unwanted garbage. But testing for
such by running
rsh user@remotehost /bin/true
produces a zero-length file, as it should, to indicate there is no «unwanted garbage» in my
startup scripts (and that command does not give
any error meesage, successfully logging into the remote host).
Just to make sure, I ran the startup scripts (.bashrc, etc) on the remote machine
via the command-line (after remotely logging on) and no output was observed.

Another thing suggested was to check whether rsync is installed and locatable by ssh.
So I ran
ssh user@remotehost «rsync —version»
and got a successful result, with no error messages:
rsync version 2.5.7 protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others

Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
IPv6, 64-bit system inums, 64-bit internal inums
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.

Running «rsync —version» on my local machine gives
rsync version 3.1.0 protocol version 31
Copyright (C) 1996-2013 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, prealloc
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.

As I say, nothing on the remote machine has changed so the error must
be resulting from some change on my local machine produced by the
ubuntu upgrade. I’ve run out of things to try that I could find on-line,
so hoping to find someone here who can see why the ubuntu upgrade might
have caused this problem.

SOLVED
In case this helps others, solution appears to be that the rsync used by 14.04
uses a different protocol than 13.10 so I must add —protocol=26 to my rsync call.

Last edited by jack_glendening; May 30th, 2014 at 05:12 AM . Reason: solution found

Источник

Thread: rsync fails after upgrade to 14.04

Thread Tools

Display

rsync fails after upgrade to 14.04

After upgrading from 13.10 to 14.04 my rsync to a remote server is now
failing with message

protocol version mismatch — is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(62)
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]

This was coming from a cron job run daily on my local machine — it
worked successfully until the day after the upgrade. I also get the
same error when running a command-line rsync ala
rsync /home/user/DIR user@remotehost/DIR

Nothing on the remote machine’s rsync or ssh has been changed (nor has
anything else of any significance)

An on-line search says this is normally due to startup scripts or
remote shell facility producing unwanted garbage. But testing for
such by running
rsh user@remotehost /bin/true
produces a zero-length file, as it should, to indicate there is no «unwanted garbage» in my
startup scripts (and that command does not give
any error meesage, successfully logging into the remote host).
Just to make sure, I ran the startup scripts (.bashrc, etc) on the remote machine
via the command-line (after remotely logging on) and no output was observed.

Another thing suggested was to check whether rsync is installed and locatable by ssh.
So I ran
ssh user@remotehost «rsync —version»
and got a successful result, with no error messages:
rsync version 2.5.7 protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others

Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
IPv6, 64-bit system inums, 64-bit internal inums
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.

Running «rsync —version» on my local machine gives
rsync version 3.1.0 protocol version 31
Copyright (C) 1996-2013 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, prealloc
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.

As I say, nothing on the remote machine has changed so the error must
be resulting from some change on my local machine produced by the
ubuntu upgrade. I’ve run out of things to try that I could find on-line,
so hoping to find someone here who can see why the ubuntu upgrade might
have caused this problem.

SOLVED
In case this helps others, solution appears to be that the rsync used by 14.04
uses a different protocol than 13.10 so I must add —protocol=26 to my rsync call.

Last edited by jack_glendening; May 30th, 2014 at 05:12 AM . Reason: solution found

Источник

rsync, scp & sftp not working for user dietpi #1703

I am unable to transfer files from my local machine to a dietpi system (DietPi v6.6 running on Raspberry Pi Zero W) using rsync , scp or sftp .

sftp (establishing connection failed):

Some further investigation showed (e.g. that serverfault question) that this issue might be related to the status output resp. banner messages after login. So I tried to disable the banner by renaming its file by

sudo mv /DietPi/dietpi/dietpi-banner /DietPi/dietpi/dietpi-banner_bak

However, the banner seems to be restored after reboot. So this did not have any effect.

As another solution I tried to disable the banner on Normal Login from inside the /DietPi/dietpi/login file which resulted in reduced output on login but does not improve anything besides that.

Might that issue be related to the banner/status output? If that is the case, how could be prevent any output on the (non-interactive) login shell?

The text was updated successfully, but these errors were encountered:

@AlbertEmil
Thank you very much for your report. We will investigate.

Hmm, since when .bashrc output created issues like this? Quick test via dropbear client works well from one of mine DietPi to another.

According to your question:

There is more output than just dietpi-banner . To test, please comment both DietPi lines within your

However, the banner seems to be restored after reboot. So this did not have any effect.

Jep, this is due to DietPi-RamDisk:

• Changed and new files will be synced to disk /boot/dietpi on shutdown/reboot, but deleted files will be not deleted on disk.
• Thus on startup, the still existing file from disk will be loaded into RamDisk /DietPi/dietpi .
• To avoid this, you would need to mv the file on both:

• But as you can see, there is still output produced, one due to now missing file. Anyway reboot is not necessary to test, logout/login is enough.

=> Comment the lines in bashrc as mentioned above. Note that these will be added on reboot, as they are essential for DietPi to run properly. So comment them, just logout/login and try your file transfer. Reboot will bring everything back in place.

After commenting both lines in user dietpi’s .bashrc as suggested

There is more output than just dietpi-banner. To test, please comment both DietPi lines within your

/.bashrc:
#. /DietPi/dietpi/func/dietpi-globals
#/DietPi/dietpi/login

the output is reduced to the bare minimum (which is more like the standard welcome message on Debian or Ubuntu systems) both scp , rsync and sftp are working as desired and files can be transferred.

However, I was able to reproduce this behavior by using either dropbear or openSSH as the SSH server on the dietpi machine and accessing the machine from Debian 9 as well as from Mac OS X 10.10.5.

@AlbertEmil
Ah, was able to reproduce the error when trying to send to user dietpi instead of root :

The only difference is that /home/dietpi/.bashrc contains sudo /DietPi/dietpi/login , as there are root privileges necessary to gather some of the banner information (mainly network related, AFAIK). Quick test after removing just the sudo :

So finally, not the output from .bashrc is the issue, just the sudo inside. I moved it into /DietPi/dietpi/login to the only place, where it really seems needed sudo /DietPi/dietpi/func/obtain_network_details and removed root privileges check at beginning of /DietPi/dietpi/login . DietPi-Banner for user dietpi looks fine, script does not produce any error (although I don’t use any autostart option, that is also done here) and rsync works as well.

@Fourdee
What do you think? Does one of our autostart options require root privileges? Games and media mainly, so should not, otherwise sudo Run_AutoStart would be needed as well 🤔 , or just for the one where really needed.

Источник

The rsync error protocol incompatibility occurs while transferring data using rsync to a remote server which has a .bashrc file.

Here at Bobcares, we have seen several such rsync command related errors as part of our Server Management Services for web hosts and online service providers.

Today we’ll take a look at the causes for this error and see the fix.

Different causes and fixes for ‘rsync error protocol incompatibility’

Now let’s see the different causes for this error to occur and fixes provided by our Support Engineers for it.

1. .bashrc outputting anything

Cause: Sometimes, if the .bashrc on the remote server output anything to the terminal then you may run into problems. Since rsync won’t expect this, it may also run into problems.

In order to check if it is the case, run the below command.

ssh remoteuser@ip-address true | wc -c

Where you would need to update the ‘remoteuser‘ with the username and IP-address with your IP address.

If the above command returns more than 0 then it means that there is some output being produced.

Solution: In order to resolve this issue, remove any commands in the .bashrc that output text, or you can try piping any output to /dev/null.

vi /root/.bashrc

if [[ $- != *i* ]] ; then
# Shell is non-interactive. Be done now!
return
fi

Manually, log in to this machine and look if you get any such message. Because for the rsync to work, you should get the remote command prompt. In case, if you receive a message, then try to disable it. Look at your shell config files (e.g. ~/.bashrc, /etc/bash.bashrc for the bash shell) if they contain any command producing this output.

2. Difference in version

Cause: If there is any difference in rsync version between source and destination servers

Solution: You can simply upgrade the rsync version so that both the source and destination servers have the same rsync version.

3. Access restriction for a user

Cause: If there is restricted access for a user to SFTP only and is jailed to his home directory

Solution: To fix this problem, undo the restriction to SFTP in sshd_config. Or create a directory inside the directory user2 jailed/bind to. This directory is owned by user1, and hence able to rsync files into it.

The process will be as below: user2 was jailed / chrooted using

Match Group sftponly
ChrootDirectory /var/ftp
ForceCommand internal-sftp
AllowTcpForwarding no

inside /etc/ssh/sshd_config.

The directory was bind to his home directory by using:

mount –bind /var/ftp /home/user2/ftp

After that, inside /var/ftp/ execute the below command:

mkdir tempDir
chown -R user1:user1 tempDir

After the files sync to that directory, they automatically appear in the user2 jail directory and the user can read them.

[Need any further assistance in fixing rsync errors? – We are here to help you.]

Conclusion

In short, the ‘rsync error protocol incompatibility’ occurs while transferring data using rsync to a remote server which has a .bashrc file. In today’s writeup, we saw the different causes and fixes our Support Engineers provide to our customers to fix this error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

enable verbose of rsync and ssh, details:

[jenkins@public-jenkins-builder1 scylla-test]$ rsync -vv -L  --timeout=300 --rsh='/bin/ssh -vv -tt -a -x  -o StrictHostKeyChecking=no -o UserKnownHostsFile=/var/tmp/tmpSijbQU -o BatchMode=yes -o ConnectTimeout=300 -o ServerAliveInterval=300 -l scylla-test -p 22 -i /jenkins/.ssh/scylla-test' -az /tmp/a.out scylla-test@10.240.0.14:"/tmp/b.out"
opening connection using: /bin/ssh -vv -tt -a -x -o StrictHostKeyChecking=no -o UserKnownHostsFile=/var/tmp/tmpSijbQU -o BatchMode=yes -o ConnectTimeout=300 -o ServerAliveInterval=300 -l scylla-test -p 22 -i /jenkins/.ssh/scylla-test -l scylla-test 10.240.0.14 rsync --server -vvlogDtprze.iLsf --timeout=300 . /tmp/b.out 
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 51: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.240.0.14 [10.240.0.14] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug1: identity file /jenkins/.ssh/scylla-test type 1
debug1: identity file /jenkins/.ssh/scylla-test-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: setup hmac-md5-etm@openssh.com
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug2: mac_setup: setup hmac-md5-etm@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: curve25519-sha256@libssh.org need=16 dh_need=16
debug1: kex: curve25519-sha256@libssh.org need=16 dh_need=16
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 65:7b:f1:d0:82:2d:67:51:f8:c7:78:ab:e7:50:99:31
debug1: Host '10.240.0.14' is known and matches the ECDSA host key.
debug1: Found key in /var/tmp/tmpSijbQU:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /jenkins/.ssh/scylla-test (0x7f0327d3a370), explicit
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1010)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1010)

debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /jenkins/.ssh/scylla-test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp d4:e8:83:6a:29:ff:0c:cb:9b:86:ff:93:b6:e6:0e:f2
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 10.240.0.14 ([10.240.0.14]:22).
debug2: fd 4 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: tty_make_modes: no fd or tio
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_CTYPE = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: rsync --server -vvlogDtprze.iLsf --timeout=300 . /tmp/b.out
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(174) [sender=3.0.9]
[jenkins@public-jenkins-builder1 scylla-test]$

Sometimes your computer may display an error stating incompatibility code 2 from the rsync error log on io.c. There can be many reasons for this problem.

Recommended: ASR Pro

Download this software and fix your PC in minutes.

For complex rsync / scp / sftp reasons, .bashrc continues to run after establishing a connection to another host. By itself, having a .bashrc is probably not a problem. Problems arise when the output of most of the commands in the .bashrc is interactive in the session.

Place these commands near the top of your .bashrc:

  # stop here for a non-interactive training run - https://serverfault.com/a/805532/67528[[rrr-! = * i *]] && back 

  # is for starting non-interactive sessions on this site - https://serverfault.com/a/805532/67528[-z "$ PS1"] && return 

All of the above commands will most effectively run other areas of .bashrc commands for interactive learning. As far as I know, human won’t need it for any other session (and in fact I’ve seen Arch and Debian’s standard bashrc use this technique as part of their bashrc).

If you want to be even more paranoid about running your own bashrc commands even for unattractive sessions, at least think about commands that can produce the product, likef on this page (link):

  if shopt -q login_shell; then   # This is an active session, we _can_ see the result    ... this includes commands that can produce output ...Fi 

Others suggest moving commands that output text to your current bash_profile, but I doubt this is still good (for reasons outlined here)

Rsync error Project incompatibility occurs when data is transferred to a remote server creating a .bashrc file when purchasing rsync.

At Bobcares, we encountered several bugs related to the rsync sort command related to our server management services for Planet hosts and online service providers.

Today we will look at the causes of this error and find a solution.

Various Causes And Remedies For “rsync Error Process Incompatibility”

Now let’s take a look at the various causes of this error and the solutions our support engineers are suggesting.

1.bashrc Provides Everything

Sometimes,

Reason: If the .bashrc on the remote server is currently pointing something to the terminal, problems may arise. Since rsync iso does not expect, problems may arise.

To check if this is the case, just run the command under the command.

  ssh  [email is being protected]  absolutely | wc -c  

Where do you need to update the actual “remote user” with the IP address of the username via your IP address.

If your current command returns greater than 0, that means output is being generated.

Workaround: To resolve this issue, remove any product-terminating commands from the .bashrc file, or try redirecting any output to / dev / null.

  vi /root/.bashrcif [[! = $ - * i *]] - then# The shell is not interactive. Done now!come back tofi  

Log on to this computer manually and see if anyone gets this message. Because a specific rsync needs a remote command line to work. If you receive a message, try disabling it later. Look next to your shell configuration (e.g. files.zB ~ / .bashrc, /etc/bash.bashrc for bash shell) to see if consumers contain a command that generates item output.

2. Differences Before Version

Reason: if there is massive sync between source and target servers

Workaround. You can upgrade your rsync version to some extent so that the source and destination servers have the same rsync version.

3. Restricting Access For Each User

Reason: if the user has a limited SFTP connection and is blocked in their home directory

Workaround: To work around this danger, remove the SFTP restriction using only sshd_config. Or create a directory in the whole directory that user2 is bound / bound to. For this reason, this directory is owned by user1 and can sync files with it.

The process looks like this: User2 was caught – chrooted with

  Match sftponly groupChroot / var / ftp directoryInternal ForceCommand-sftpAllowTcpForwarding no  

  mount - bind / var / ftp / home / user2 / ftp  

  mkdir tempDirchown -R user1: user1 tempDir  

After the files are synced to this directory, they will automatically appear in the user’s 2 jail directory so thatusers could read them.

[Need more help troubleshooting rsync errors? We are here to serve you.]

… …

Conclusion

…

In short, a .rsync protocol incompatibility error occurs without .rsync data with an absolute remote server that has a .bashrc file. In today’s report, we came across various causes and fixes that One Person Support is providing our men and women to help resolve this error.

PREVENT YOUR SERVER FROM DAMAGE!

Never lose below average clients due to server speed again! Let us help you.

Our server specialists take care of your server around the clock, ensuring its lightning speed and security.

Download this software and fix your PC in minutes.

Rsync Foutprotocol Incompatibiliteitscode 2 Op Io C
Codigo De Incompatibilidade De Protocolo De Erro Rsync 2 Em Io C
Kod Niezgodnosci Protokolu Bledu Rsync 2 W Io C
Codigo De Incompatibilidad De Protocolo De Error De Rsync 2 En Io C
Codice Di Incompatibilita Del Protocollo Di Errore Rsync 2 Su Io C
Code D Incompatibilite Du Protocole D Erreur Rsync 2 Sur Io C
Rsync Fehlerprotokoll Inkompatibilitatscode 2 Bei Io C
Rsync Felprotokoll Inkompatibilitetskod 2 Pa Io C
Io C의 Rsync 오류 프로토콜 비호환성 코드 2
Oshibka Nesovmestimosti Protokola Oshibki Rsync Kod 2 Na Io C

Today my GitHub Action workflow suddenly could not work, when I run into rsync command, shows this error:

Run AEnterprise/rsync-deploy@v1.0
/usr/bin/docker run --name a33c16623b7699cd84934b858311cbdd386ab_beae30 --label 8a33c1 --workdir /github/workspace --rm -e JAVA_HOME_11.0.11_x64 -e JAVA_HOME -e JAVA_HOME_11_0_11_X64 -e DEPLOY_KEY -e ARGS -e SERVER_PORT -e FOLDER -e SERVER_IP -e USERNAME -e SERVER_DESTINATION -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true --network github_network_6569d291c303459885993b766ea4e6e0 -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/retire/retire":"/github/workspace" 8a33c1:6623b7699cd84934b858311cbdd386ab
Warning: Permanently added '***' (ECDSA) to the list of known hosts.
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(178) [sender=3.1.2]

and this is my GitHub Action async part ci script:

   - name: Copy jar to Server
      uses: AEnterprise/rsync-deploy@v1.0
      env:
        # use pre-configured secret (the private key)
        DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
        ARGS: -avz --delete
        SERVER_PORT: "22"
        # folder to push (./ is the root of current repo)
        FOLDER: ./dolphin-post/dolphin-post-service/build/libs
        SERVER_IP: ${{ secrets.BINGQIAN_HOST }}
        USERNAME: ${{ secrets.BINGQIAN_USER }}
        SERVER_DESTINATION: /opt/apps/dolphin-post
 

why suddenlly could not work, I did not do any change of this ci script. what should I do to fix it? By the way, I have tried rerun the ci workflow for many times but still not work.