Syncthing copied files to wrong server

Hi to all here, I started to deploy Syncthing yesterday (after being not convinced by NextCloud for my demand) using this (local NW only) environment:

  • Server (v1.23.0, Linux (64-bit Intel/AMD Container)) on OpenMediaVault Docker Container using the standard script for stacks (modified user/groups/volumes according to my setup)
  • Client (Win11, Synctrayzor, latest Version as well)

While I had several attempts to connect both instances - the following lines in the log catched my attention:

GHDUB] *INFO: quic://0.0.0.0:22000 detected NAT type: Port restricted NAT [GHDUB] *INFO: quic://0.0.0.0:22000 resolved external address quic://82.207.246.174:21748 (via stun.syncthing.net:3478) [GHDUB] *INFO: Joined relay relay://178.32.1116:22067 [GHDUB] INFO: Adding folder uudyh- :bomb:

and then Syncthing started to synch a few files to 178.32.111.** - which is a server somewhere in France (according to IPLocator) - before I hit the cancel button.

Most likely my connectivity config was on standard

Just to understand it:

  • How could it happen that my folder ID started to sync on a server somewhere in the internet? I never entered any IP outside of my local NW.
  • Any chance to re-connect to this server and delete the files? Since no credentials where asked so far - I assume I could re-connect. But I would need to understand how - since it happened.

Lesson learned:

  • Blacklisted all (known) relay servers + stun.syncthing.net + ports for Syncthing in the internet firewall
  • Watch my NW traffic while using Syncthing - sorry, but I am very cautious now

Actual Situation:

  • Within NW all devices (incl. Mobiles) sync as expected (yeah!), just some files from my hard disk fly arround the internet now (not so yeah!)

Can anyone please enlighten me on how this could happen?

Thanks a lot, Toko

Syncthing uses relays when it cannot establish a direct connection. It’s not that your files were synced there, the (encrypted) traffic was bounced there.

3 Likes

Thanks Jakob for the quick reply. Do you still have the same statement - after looking at the following lines of the LOG-file mentioned above (yes, I realize I should have shared it earier). Filenames adjusted …

  • [GHDUB] 2023/01/31 16:12:14 INFO: Ready to synchronize uudyh-**** (sendreceive)
  • [GHDUB] 2023/01/31 16:12:16 INFO: Normalized UTF8 encoding of file name “Office\Lotto Results 2023.pdf”.
  • [GHDUB] 2023/01/31 16:12:16 INFO: Normalized UTF8 encoding of file name “Office\Kennedy Case - Solved.pdf”.
  • [GHDUB] 2023/01/31 16:12:33 INFO: Paused folder “Default Folder” (default) (sendreceive)

The last entry was, when I did hit the “cancel” button:

Besides what happened here: I am really amazed how reliably Syncthing seems to be. No issues with >100K Files and several devices. Compared to Syncthing - I had so many challenges with Nextcloud (CPU load, got stuck, did not properly sync all files, had issues with date of files, stumbled about file name characters etc).

1 Like

Maybe we should have a feature where it reports future lottery numbers to the Foundation, but we don’t. :slight_smile:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.