I receive Urbackup connecterror 2 with no network issues. Today initiated Backup from GUI and received a connecterror-2 for the same PC where GUI was up for initiation. Had remote desktop open to the windows host for the virtual Server (Debian) from the same client as well. Client internet access was active in addition with no issues. No issues reported in client and server system logs. Overall no network issues reported by any system, except urbackup backup function. Ping worked forth and back prior and after connect error between client and server. Protocol lists no obvious reason. Problem occurs on all win7 clients more or less regular, assume time since last reboot is the main factor.
The only corrective action working seems to be rebooting the client - usually after reboot the issue is gone for some time for the rebooted client, but comes back after some days without reboot.
Not sure what causes the issue, but due to correction with client reboot assumed it could be a client issue. Summary Protocols client and server are attached.
Client : Win7 Home premium x64, Update status current. Server Debian 64 virtual Updatestatus current, separated via Network Bridge from Windows host.
This error is logged if it cannot connect to the client. You should look for networking issues – from firewalls to switches. As last resort you can always use something like Wireshark to see what connection requests are accepted/dropped.
Hello Uroni,
have checked via MS Network Monitor. Issue appeared now first with a Vista client, but believe it makes no difference to Win7. There are no Network issues.
Network shows a lot of communication on Port 35623 when a full file backup is initiated via GUI. After about 57 minutes of frame exchange (about 4200 frames) on Port 35623 there are 4 frames from server to client on port 35621, no response on that port from client.
Afterwards there are still frames on port 35623 exchanged between client and server, but with a timedistance of about a minute per bundle. No Traffic on Port 35622. However, Protocol reports connect error (not connect error 2 in this case).
There is still network traffic ongoning on other ports - GUI, Samba, etc. No network issue at all and obviously still traffic on port 35623 between client and server. Have not enough detail to validate contents of frames, but loks to me like an handshake issue between client and server. Full capture from MS Network monitor is saved and can be made available in case you are interested.