Syncthing multi user and local discovery

I use two instances of Syncthing on one machine, each instance for a user. Whatever I do, one of these instances never manages to find other local nodes via local discovery and only connects to them via global discovery (internet IP). Here is what I tried. In ~./config/syncthing/config.xml I changed:

  • <listenAddress> from to, so both instances have a unique <listenAdress>
  • <localAnnouncePort> from 21025 to 21027
  • <localAnnounceMCAddr> from [ff32::5222]:21026 to [ff32::5222]:21028

I tried all possible combinations and nothing succeeded. Of course, <localAnnounceEnabled> is set to true. What am I doing wrong?

Can you provide STTRACE=discovery logs?

Can you explain or link how to do that?

The localAnnouncePort and localAnnounceMCAddr must be the same on all devices who are going to find each other on a LAN. The first is used for IPv4 broadcasts, the second for IPv6 multicasts.

For IPv4 broadcasts, only one program can open the port at a time, so only the first syncthing you start will be able to use discovery over IPv4. The IPv6 multicasts don’t suffer from that limitation, but require that you have IPv6 enabled on your computers (which ought to be the default pretty much everywhere though).

Two syncthings on the same machine won’t find each other though, multicast or not, but in that case you can simple set the addresses statically.

1 Like

Thank you for explaining. It makes sense, now. I checked again and realized, local discovery via IPv6 works with other clients. You are right, it doesn’t work with two instances on the same machine.

but in that case you can simple set the addresses statically.

I’m not sure, if I understand that. Giving the machine with the two instances a static IP? How is that going to help? The config file of both instances already has fixed ports and addresses, doesn’t it?

As for one and on the other, I was thinking.

I changed listenAddress from to for the first instance and for the second instance from to on the same machine. With that setting active, neither local nor global discovery works. Both instances won’t see the other. Using the addresses, global discovery worked, at least.

I kept digging a bit into the local discovery. I will call the machine with the two instances running the server and the machine I’m working on the client. I realized, that the IPv6 address my Syncthing client connects to is different from the IPv6 I get from “ping server”. The first 4 phrases (xxxx:xxxx:xxxx:xxx) are the same but for the next 4 phrases, they differ (x00:000x:00x0:00x0 vs 0000:x0xx:xx00:xxxx). So I disabled “global discovery” for the Syncthing client and the server to check, if the machines connect via internet or via LAN. With this setting applied, Syncthing client will find only the first instance on the server. The second one is practically unavailable in the local network and connection to it can only be established via internet.

I uploaded a log file and the configuration files.

Here is the output of STTRACE=discover ./syncthing: It is the second instance and has been started after the first instance on the Syncthing server. It’s configuration file is here:

The configuration file of the first instance on the Syncthing server is here:

The configuration file of the Syncthing client is here:

So you should add additional localhost addresses for the devices.

Instance one should have address for instance two: dynamic And instance two should have addresses for instance one: dynamic

Thank you, @AudriusButkevicius. I misunderstood the address field @calmh was walking about. I was still fiddling on listeningAddress, overlooking the address fields for every device. The address field set to dynamic, for instance two and dynamic, for instance one, both can connect without global discovery. Note, I had to add a comma when using the WebGUI before it worked.

However, the server instance started last still cannot be discovered from my Syncthing clients via IPv6 when global discovery is disabled. What is the problem here?

Well check STTRACE=discovery on that device (and some adjacent peer you expect to discover that device), and make sure it actually has a v6 address.

This is the log file on the device. While I check other logs on adjacent peers, is it enough to check if


points to a v6 address?

Ok, you need STTRACE=discovery,beacon probably. Is the localAnnounceMCAddr defined?

I run all three instances, two on the server and one on the client, with STTRACE=discovery,beacon. The log files have no obvious error messages. The first instance on the server is able to connect to the client (IPv4). The log file of the second instance on the server never mentions the Syncthing client (except for the beginning, where it lists all known nodes). Also the log file of the Syncthing client never mentions the second instances node ID (again, except for the beginning).

All three instances have the same localAnnounceMCAddr and do not use global discovery. When global discovery is set to true, the nodes find each others IPv6 (if IPv4 port is already used ).

Maybe this detail helps? Both instances on the server have the following line repeatedly in their log files:

[XXXX] 2015/03/12 17:58:41.164905 multicast.go:75: DEBUG: sent 56 bytes to [ff32::5222%eth0]:21026

But the Syncthing client’s log file never shows that line.

Yeah, I think this is where my v6 knowledge ends.

Maybe it’s a bug? Is there a reasonable explanation why Syncthing on the client won’t use multicast.go while Syncthing on the server does?

Well I am not sure its not using it. You only post a line rather than a whole log, and it’s not clear which device it is etc.

Sorry, here are the details, logs and configs!

Server instance A has been started first and thus can connect to the client via local discovery. Because of the static address field, it can also connect to server instance B. Client has been started after Server instance A. It is the only log not listing multicast.go messages.

Server instance B has been started after the client. As you can see from the logs, it fails to find any other node except for server instance A due to the static address field.

All instances have been started with STTRACE=discover,beacon. Client is Win7x64, Server is Ubuntu 14.04 ARM.

Syncthing Server Instance A log file: Syncthing Server Instance A config file:

Syncthing Server Instance B log file: Syncthing Server Instance B config file:

Syncthing Client log file: Syncthing Client config file:

Well the error message is there and clear:

[TJ3HG] 2015/03/12 21:20:48.360823 discover.go:88: DEBUG: discover: Start local v6: listen udp ff32::5222: setsockopt: not supported by windows
[TJ3HG] 2015/03/12 21:20:48.360823 discover.go:90: INFO: Local discovery over IPv6 unavailable

It seems Go lacks IPv6 support for windows. Hence no local discovery over ipv6 for windows.

Thanks. After seeing these logs 10 times on Linux, I always skipped the first lines…

So using several instances of Syncthing on one machine, every Windows client needs to know the specific alternate IPv4 address port of each instance or one accepts the lower upload rates and uses global discovery.

It seems, my best bet it to wait until Go supports setsockopt on Windows.

Thank you for your help!

More information about Go supporting setsockopt on Windows is here: