Ubuntu server running syncthing.
Mac Workstation running syncthing.
On the server, I add a remote device and my workstation ID is identified under “You can also select one of these nearby devices.”
So I click that ID, leave device ID empty, and click save. The device appears in Remote Devices briefly, then disappears.
While the device IS shown in remote devices, I note that the name of the remote device is the first 6 characters of its ID, and the IP address of the device is correct, with a listening port of :51443.
The workstation never sees an inbound notification that a remote device wants to connect and therefore no sync can be setup.
Am I doing this incorrectly?
Is there significance to the port that the workstation is listening to?
Do I need to add each device on the other’s setup to create a connection?
My devices on my router are assigned IP’s using the MAC address, so they’re static in a DHCP environment. Should I switch from default in sync protocol listen address to the fixed IP for each machine?
Looks like you’re using the LAN discovery feature (Local Discovery Protocol) of syncthing (“nearby devices”). I have never used this, so I can’t give advice on that.
However, when adding a new device both sides need to add each other. So on device A you add the ID of device B and on device B you add A. This is neccessary for security, to ensure that the connection is intended.
I guess that it is very similar with the LAN discovery, so you should attempt to add both devices on both sides. If that doesn’t work, ignore the “nearby devices” and try to add the devices manually by typing in IDs.
The second I disabled local discovery on both devices and restarted the service on each machine, the actual names of the remote devices resolved on each UI and the Last Seen immediately updated.
Now, what I’m trying to wrap my head around is why both UI’s show remote devices with a relay address along with the public IP address for the tcp:// address.
Enable Relaying is on, but I’m not certain if I need that.
Ultimately, I need all of my workstations in this network to connect to the server, and then I need the server to connect to my other server across town. So, the Ubuntu server is the only one that needs to be exposed to the public IP.
Ideas? Thanks for the help by the way. Haven’t tried sharing a folder yet…I presume that challenge is next.
You shouldn’t have to disable local discovery, quite the contrary when all your devices are in the same network.
I don’t really understand, you first say the devices appears shortly and then disappears, and then that the device is there. Which is it? Also please take screenshots and share them, they are the simplest way to show the situation.
I’m not entirely sure if I’m correct because I have never tried this scenario, but I guess that disabling local discovery is creating problems.
Without local discovery, I presume that the devices never learn each others private address and only receive the routers public address from the global discovery server somewhere in the net.
This could cause the devices to only connect via relays, which is definetly bad. Never prefer relay connections, those are fallback options if everything else fails.
At this point I’m not entirely sure what your issue is now - I understand you have successfully added every device to your cluster, but with local discovery turned off? What happens if you re-enable local discovery?
As for the connection stuff: Syncthing performs best effort to determine port numbers and IP addresses on it’s own. You rarely need to configure anything manually. Note that syncthing doesn’t really folllow the concept of server and client. Syncthing creates a TCP server socket and TCP client sockets as needed. It is not predetermined which side gets TCP server and which gets client - this is decided on simply “what works first”. The port number used for the TCP client is also dynamic which is the likely reason why you saw port 51443 on one device.
I’m in the middle of a folder sync as it seems to be working.
I’ll try re-enabling local discovery, but I’m suspecting the original problem stemmed from my failure to restart the services to begin with to make sure all configuration was set. Although, on my server/workstation setup at home, I didn’t have to restart…or perhaps I’m mistaken.
Either way, everything you’ve written makes perfect sense. As soon as the current sync is done, I’ll switch back to local discovery because I do in fact think that Syncthing is using relays for the whole shabang right now.
Doesn’t that mean that it’s going through extra motions that it doesn’t need to be going through? Will synchronization be faster and safer if it’s not using relays?
Now, on another note, my server at home is showing up on this server here as a remote device that wants access, which by my calculations is pleasantly correct, since I had added this server’s ID as a remote device on that server. ;).
Yes, if it’s connecting over relay it’s likely going to be quite slow. You can enable local discovery at any time, it will automatically switch to a better connection if possible (everything is better than relay ).
Any idea what would cause the workstation, in the middle of a sync, to report “folder marker missing” while the server still appears to be syncing the folder anyway?
Folder marker missing means the entire directory where your folder is located is missing. The remote may be processing some information that were collected before this incident and thus still seem syncing, but it won’t finish.
).