Syncthing devices are suddenly disconnected, context deadline exceeded and i/o timeout

Set up syncthing (1.2.1-1) for the first time roughly 8 hrs ago, on both my laptop and this desktop, both running Linux. Syncing files worked flawlessly up until 1 hour ago, when I came back to the desktop and checked the web GUI. It showed my laptop is disconnected and the laptop’s web GUI says the same about the desktop PC.

When I click on the respective machine, it lists lots of quic- and tcp-addresses with either “i/o timeout” or “context deadline exceeded” in between.

What should I do? Any help would be greatly appreciated.

This is not entirely uncommon. I won’t pretend to understand why devices “disconnect” themselves so often, but if the folder says that the files are all in sync, and the devices check in with each other periodically then you should be good to go. Try creating a file on one device and then see if any activity indicates it syncing. If the file does not appear on the other device then you might have issues, but the mere status of “disconnected” does not necessarily mean you have issues.

If they are disconnected they probably cannot connect. Why they cannot connect I can’t answer as they should always be able to connect over a relay.

Oh, no, they did not sync, i.e. nothing was shared/uploaded or anything. I actually wanted to sync files (by which I mean I had unwillingly executed your described attempt).

I shut down both machines shortly after my post and the next morning, everything synced flawlessly again.

I’m experiencing this as well. Nothing syncs; it’s a miracle to even get devices to achieve something other than “Disconnected” for a second or two, even if I try to remove + re-add devices (EDIT: waiting around for about 10 minutes resulted in a connection + sync between the manually re-added devices; no others).

In case background is helpful, I sync a Linux desktop to backup a Windows laptop (using SyncTrazor), that in turn syncs pictures with an Android phone. I noticed today that none of my devices have seen each other since May 12 (which is scary, as some pretty important things haven’t been synced in all that time…).

Here’s a sample of the errors:

 Address	dynamic
quic://150.135.165.33:22000
context deadline exceeded (13:53:17)
quic://150.135.165.45:22000
context deadline exceeded (13:53:17)
quic://150.135.165.55:11696
context deadline exceeded (13:53:17)
quic://150.135.165.55:17558
context deadline exceeded (13:53:17)
quic://150.135.165.55:22000
context deadline exceeded (13:53:17)
quic://150.135.165.55:42985
context deadline exceeded (13:53:17)
quic://150.135.165.55:64784
context deadline exceeded (13:53:17)
quic://150.135.165.55:8195
context deadline exceeded (13:53:17)
quic://150.135.165.56:22000
context deadline exceeded (13:53:17)
relay://162.255.117.212:443
relay://184.176.124.205:46900
tcp://150.135.165.33:22000
i/o timeout (13:53:07)
tcp://150.135.165.45:22000
i/o timeout (13:53:07)
tcp://150.135.165.55:22000
i/o timeout (13:53:07)
tcp://150.135.165.56:22000
i/o timeout (13:53:07)

Can you please provide logs from both sides.

Ideally full logs.

1 Like

Seeing the same thing between two machines.

dynamic quic://37.157.97.155:22000 context deadline exceeded (15:28:47) quic://37.157.97.155:7920 context deadline exceeded (15:28:47) relay://79.136.5.160:22067 relay://95.216.197.147:22067 tcp://37.157.97.155:22000 i/o timeout (15:28:37

Please provide logs. We do not ask because we challenge that there is a problem at all or to annoy you, we ask because that’s the only way to have a chance to see what the problem is and eventually hopefully fixing it.

2 Likes

I had the same problem after installing my firewall. Do you have a firewall installed? If so, you need to create some rules to allow that syncthing traffic through.

I struggled with this issue for a few days now, too. It seems that it was cause by the NAT traversal setting. When off, syncthing works again.

My guess is: I configured all syncthing to listen on my relay and :22000. Some nodes are within the same NAT and somehow (since ~1.2.x) this posed a problem when NAT traversal was set to on, because maybe they tried the external IP with :22000 instead of local connections (local discovery).

Any thoughts from the experts?

PS: Now it works for ~5 mins then the transfer rate go down ~100byte/s again :frowning:

^