I am setting up rsync to synchronize files between two separated servers (A and B) in different networks, both running Solaris 10 OS. I am using --daemon.

Right now, I am able to get the module list of server B from server A, as well as downloading files from B to A. However when trying to upload files from A to B the process hangs.

Analysing the log files generated by rsync I can see that the connection between the servers is established but then lost.

Log file server A:

root# rsync -rltgD --progress testfile x.x.x.x::test/

building file list ...
1 file to consider
rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32)
rsync: read error: Connection timed out (145)
rsync: error: error in rsync protocol data stream (code 12) at io.c(604) [sender=2.6.9]

Log file server B:

[4799] connect from UNKNOWN (x.x.x.x)
[4799] rsync to test/ from UNKNOWN (x.x.x.x)
[4799] receiving file list
[4657] rsync: read error: Connection timed out (145)
[4657] rsync error: error in rsync protocol data stream (code 12) at io.c(604) [receiver=2.6.9]
[4657] rsync error: error in rsync protocol data stream (code 12) at io.c(453) [generator=2.6.9]

Permissions in the destination (Server B) are defined as chmod 777. Inetd is configured to allow rsync with anonymous access. I tried changing paths and ownership so it would be equal in both servers, no luck. I also matched the versions to 2.6.9 as well as using Virtual Machines and Physical machines, the problem remains. I also tried with different OS, namely CentOS and Windows 7 Professional. Using these rsync clients I can sync files with server B without any problem (these machines are in the same network as server B). I captured the packets of a successful synchronization between server B and the CentOS 6.7 machine and compared them with a failed synchronization between server B and server A, I reached the same conclusion drawn from the log files: the TCP and rsync connections are established, but the files are not transfered.

Any help regarding this problem is deeply appreciated. Best Regards.


If anyone has this problem, I solved it with the MTU parameter. Since server B had ICMP protocol blocked, MTU value was automatically defined to 1500 bytes. When this value was changed to 1280 bytes on server A, the connection started working as it should.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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