Summary: Rsync fails with older version.
AssignedTo: [hidden email] ReportedBy: [hidden email] QAContact: [hidden email]
Does not work:
Rsync version 3.1.0
Protocol version 31
rsync version 3.0.9
protocol version 30
In both cases: "server side":
protocol version 21
with both "client" side rsyncs I of course get:
> Server is very old version of rsync, upgrade recommended.
but with the newer rsync I get:
Warning: No xauth data; using fake authentication data for X11 forwarding.
Server is very old version of rsync, upgrade recommended.
protocol version mismatch - is your shell clean?
(see the rsync man page for an explanation)
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226)
According to the manpage I can test the "is your shell clean" with
ssh oldserver /usr/bin/true > out.dat
but I get a clean file (0 bytes).
I just checked: the "no xauth data" doesn't matter:
rsync -e "ssh -x" vsuse:/etc/issue .
has the same problems.
The Ubuntu guys asked me to report this here....
I used "git bisect" for the first time. The commit that caused this problem is:
[8b3e60523aa3d86583a1df54c81c9d480ea19740] Improved the fix that ensures that
the generator gets notified about an I/O error for the incremental directory
that generated the error. The PROTOCOL_VERSION was bumped to 31 to implement
What |Removed |Added
--- Comment #2 from Wayne Davison <[hidden email]> 2014-04-24 15:33:28 UTC ---
rsync 2.3.2 won't interact with protocol 31 -- it is too great of a protocol
number for it. You should upgrade that super-old rsync. Alternately, you can
specify a protocol number on the client's command-line to make the old-rsync
--- Comment #3 from Roger Wolff <[hidden email]> 2014-04-27 10:17:59 UTC ---
My arguments for seeing this as a bug are:
1) The rsync version of half a year ago /is/ able to communicate with that old
2) The patch comment for the patch that "removed" compatiblity did not mention
that it would break compatiblity.
3) I encountered this when ubuntu trusty-tahr would not rsync with suse 7.0,
but Saucy Salamander would. Thus the incompatiblity was introduced quite
recent. Having the ability to copy files to and from older systems (real or
virtual) is useful.
Suppose I saved the disk from an older system and now want to recover the files
from it. Boot an old motherboard with the harddrive and just rsync the files is
very useful. Oh. Just connect the drive to a system and copy the files? Yeah.
Maybe thats sometimes quicker.
In the case at hand, I had to run some very old software, that wouldn't run on
a more modern distribution. (or at least, I knew it ran on THAT old
distribution, and I managed to "fast-forward" eventually to find the latest
versions that would work.) Getting modern software to compile and run on an
older distribution is troublesome. Try and upgrade a package like SAMBA to the
latest version on a "still supported" LTS release (e.g. Ubuntu 10.04 Lucid Lynx
Now if there is a fundamental issue with the protocol I understand that at one
point you have to break the backwards compatiblity. But in incrementing the
protocol version number from 31 to 32 I don't see a fundamental reason reason
to break protocol V21 compatibilily. It's probably some typo that causes
things to go awry and not a fundamental issue.
For something like "ssh" I could understand a: "protocol version is too old.
That version has fundamental security issues. Specify --force to force the
--- Comment #4 from Wayne Davison <[hidden email]> 2014-04-29 17:13:13 UTC ---
Rsync 2.3.2 refuses to interact with protocol 31. If you wish to tweak 2.3.2
to not be so draconian, please be my guest, but you'd be better off upgrading
the hugely ancient rsync instead.
There's nothing that a modern rsync can do about the refusal of an old rsync to
interact with it since it must advertise its maximum protocol (and it doesn't
know how old the server is beforehand). More modern rsyncs are more forgiving
about allowing later versions, but only up to protocol 40 at present. It would
be nice to remove the max-protocol check altogether, but the check was added to
try to figure out when it received some ascii garbage instead of a valid
protocol value, so we need a better "I got garbage" check (which should really
have been implemented in a better manner from the start).
So, if you run into an old rsync and you can't upgrade it, just remember to use
--version=30 to work around its deficiency.
--- Comment #7 from John Jacq <[hidden email]> 2014-04-29 18:58:19 UTC ---
Thanks, this does work fine. I've simply aliased rsync to "rsync --protocol=30"
in my .bash_aliases file so as not to change my backup scripts.
Updating rsync on the remote machine would be better but I'm not the
--- Comment #8 from Roger Wolff <[hidden email]> 2014-04-30 07:40:41 UTC ---
Ah! It is the OLDER version of rsync that is refusing to talk to the newer one.
I would always have implemented protocol version compatiblity by having the
newer version make the decision.
--- Comment #10 from Roger Wolff <[hidden email]> ---
FYI: I still think this is relevant, and the current "structure" is not
The machine in question was installed in 1996, it serves a single purpose (in
an industrial environment) and it serves it well. But for maintenance it is
useful to be able to copy files in and out of that machine.....
(back then... I managed to convince the powers-that-be that it was NOT
appropriate to arrange an internet connection for that machine... So it is NOT
on the internet... Thank god.)
You are receiving this mail because:
You are the QA Contact for the bug.