Hello, first time poster, so sorry if I’m breaking any rules. I’m trying to understand if the behaviour I’m seeing with my Syncthing install is a bug or a wrong setting on my behalf.
I have a very strict setup between 4 machines, A, B, A backup, B backup. A and B mainly sync to their backups, in order to have a failsafe in case of a malfunctioning. However, storage is synced across all machines.
I keep having this bug, every now and again, where all of sudden syncthing syncs the wrong things to the wrong machines. Or better: it syncs non storage items, to machines that should only share storage, thus rewriting files.
The last time this happened, this was triggered by windows asking if this pc should be seen on the public wifi network. As soon as I pressed yes, the whole issue happened.
Any help would be welcome, happy to give more details if needed.
Can you post screenshots of the Syncthing Web GUI from all devices?
Also, have you be any chance cloned Syncthing configuration between the devices when setting them up for the first time? It sounds like you may have two (or more) devices with the same ID (that can only happen if you clone and re-use Syncthing key files, which must never be done). This is just an assumption based on what has been described above though. The screenshots should clear it up.
Hi @tomasz86, thanks for the quick response and sorry if the Syncthing UI in the pic is in Italian.
We always set up the Syncthing environment from scratch, so there should be no issues related to cloning. Devices cannot have the same ID, because at setup, we always double check that every device has a unique ID.
This screenshot is not from the machine that is currently exhibiting the misbehaviour, but the setup is the same for all of our machines. Hope this helps to clear things up.
Don’t know if it helps, but I thought that sharing our internal guide on “how to setup Syncthing” might help uncover the mystery.
Associate a name with each machine in the setup for network recognition.
Set “Generic” IP address to 0.0.0.0:8384, User and Password required for accessing the interface, enable “Use HTTPS for GUI” and disable “Start Browser”.
In the “Connections” tab there is only one parameter “Synchronization Protocol Addresses” to be set. The syntax to be reported is tcp4:/ /IPCURRENTMACHINE:22000, quic:/ / /IPCURRENTMACHINE:21000. TPC4 allows listening on all interfaces only via IPv4, while QUIC “Quick UDP Internet Connections,” in turn refers to sending data packets quickly and easily. This is made possible by the UDP protocol it uses.
Synchronization settings. Add the folder you want to make available for sharing.
Give the folder an ID and the path to the folder on the local machine, in the “General” tab.
Sharing section shouldn’t be usable if no remote devices have been associated yet. If you have followed the steps correctly instead, select the devices with which to share the folder.
Enter an asterisk and then the name of the file or folder to be excluded in the “File Exclusion Schemes” if needed.
Select from the list of available IDs, the one in reference to the machine to synchronize with. Also provide a name for the ID:
In the “Sharing” section, choose which folders to share with that specific remote device:
Finally, in the “Advanced” tab, you need to specify the addresses of the remote device, with the syntax:
tcp4:/ /IPCURRENTMACHINE:22000, quic:/ /IPCURRENTMACHINE:21000.
Step 10 sounds wrong. The remote device will usually not have the same addresses as you have configured for the local device under Synchronization Protocol Addresses.
Overall, I find your instructions a bit convoluted and hard to follow. Might be caused by some translation errors though.
Hi @acolomb, thanks for replying. The steps were just a way to bump up the post by giving a bit more context. The steps are auto translated (sorry, lazyness) and summarised just to give some context. The real step-by-step guide is much more detailed and has a lot of things that I purposefully removed for the sake of brevity (i.e. click on this tab, then on this button and fill in this field).
The remote device does not have the same address. Each device has it’s own IP, to enable sync. That’s why there is the IPCURRENTMACHINE placeholder. If I’m working on machine 1, it will be something like tcp4://192.168.1.1:22000, quic://192.168.1.1:22000, and when I move on machine 2 it will be tcp4://192.168.1.2:22000, quic://192.168.1.2:22000
Sure, but in your instructions, you say that this IPCURRENTMACHINE needs to be entered under “Synchronization Protocol Addresses” (step 3). Then in step 10, the same addresses with IPCURRENTMACHINE should be entered on that same device in the “Advanced” tab “of the remote device”. That means it will try reaching a remote device under the same address that the local device itself is bound to, which does not make sense.
I just double checked the guide, and you are correct: when setting up remote connections, the syntax is tcp4:/ /IPREMOTEMACHINE:22000, quic:/ /IPREMOTEMACHINE:21000. I am so sorry for the mistake.
Regarding the port, I have no idea why we’re using 21000 for QUIC. This workflow was already established when I arrived.
OK so now we have the obvious questions cleared up. The basic setup seems to be alright and if I understand you correctly, it is mostly working as well.
Can you give a concrete example of what actually goes wrong? Sorry, I don’t understand what you’re talking about with “non storage items” and where they are synced and should not be.
Check which devices show each other as connected. Check again which devices each folder is shared between. Then tell us what exactly you see that should not have happened in your setup.
The mediaserver folder is where things get tricky. Supervisors and Mediaservers both have a mediaserver folder, but this is separate and different between the two clusters. Picture above shows the mediaserver folder that needs to be shared only between the Supervisors.
This picture instead shows the other mediaserver folder shared only between the Mediaservers.
When the issue appears, it seems like Syncthing cannot recognise the two separate instances of the mediaserver folder, and chooses one folder to push to all the machines in the system. Effectively overwriting all files, and ignoring whether they are Supervisors or Mediaservers.
My guess is you have one machine that shares the folder more than you intend. It’s hard to tell with a fractional screenshot from one unknown machine. Check them all.
Hi @calmh, unfortunately that’s the first thing we checked. Both at setup and when the problem appears, all the machines are setup correctly. There is no machine that shares the folder more than we intend.
Yeah… then I don’t know. Syncthing doesn’t sync data to a different folder ID on a different machine it’s not shared with. Maybe something else in your setup does, or someone made a manual mistake thinking c:\mediaserver on machine A was in fact c:\mediaserver on machine B
Are the two devices in a “Disconnected” state included?
Based on your screenshots, there are 8 devices total: 4U-MINI-005, 4U-MINI-006, 4U-MINI-007, 4U-MINI-008, 4U-MINI-009, 4U-MINI-010, 4U-PRO-001, 4U-PRO-002
Please post screenshots of the “mediaserver” folder panel in Syncthing from all 6 “Mediaservers”. Be sure to clearly label each image (or at least the image filename) so that it’s easy to tell which device it came from.
I agree, Syncthing doesn’t care about the label “mediaserver” being the same between different folders. All that matters is the folder ID. However, the path seems to be C:\mediaserver in both cases. So my hunch is that some device might be unintentionally sharing that same folder path under both IDs. Whenever it comes only, it causes both shared folders to be effectively merged and have the same data. As long as it’s offline, it doesn’t cause that issue.
Indeed we don’t have enough information to diagnose this. You’ll need to check which devices that “mediaserver” folder is shared with on all the devices. Maybe this little utility can help you get an overview:
