Separate Syncthing installations on both local machine and WSL

Has anyone got this working or is it even possible?

I was tinkering with WSL today and installed Syncthing. Upon starting the service, it told me it was already running - it’s running on Windows 10 (the local machine). WSL does not use systemd. It has it’s own thing to manage services and I’m not sure how it works.

I wanted to set up Syncthing on WSL, because there is a significant performance hit running node modules on WSL with files on the local Windows machine. I guess Docker is an option, but I have no experience with that.

Do you mean that you want to run multiple instances? If yes, then you just need to specify different home paths for each of them (see You may also want to tweak ports and such so that they don’t overlap.

If the above is the case, then I’d suggest to search the forum for “multiple instances”, because this has been discussed here plenty of times :slightly_smiling_face:.

No, not multiple instances. I want Syncthing installed on both Windows 10 (local machine) and WSL. If you are not familiar with WSL, it stands for Windows Subsystem for Linux. It’s a Virtual Machine that integrates directly with Windows. I want to sync my coding folder from Windows 10 to WSL for the best performance with node modules.

I have Syncthing installed on both Windows 10 and WSL. The problem is if I try to run Syncthing on WSL, it says it is already running and fails. That is because WSL does not have a service manager. So Syncthing on WSL, is actually just the same Syncthing install on Windows 10, even though it’s installed on WSL and has a different path.

Yes, I do know what WSL is :slightly_smiling_face:. The problem you’re describing sounds exactly like what happens when trying to run multiple instances though. I’m quite sure that it can be solved by running Syncthing using custom home paths.

Basically, what you need to do is to run syncthing.exe -home=<path1> from your main Windows installation, and syncthing -home=<path2> from inside WSL. If you don’t specificy custom home paths, Syncthing probably tries to use the default path (see, which likely ends up being the same both for the main OS and WSL.

What do you mean exactly by “installing” Syncthing though? The archive from the official website contains just the syncthing.exe binary, which cannot really be installed in any way, just run directly. If you’re using SyncTrayzor by any chance, I think it does offer options to use custom home paths. Otherwise, you’d need to switch to the portable version of SyncTrayzor in order not to overlap the paths.

I checked the config file and it’s definitely pointing to a different path.

Windows 10: C:\Users\LV426\Documents\Syncthing WSL: \wsl$\Ubuntu\home\LV426\Sync\

I confirmed both Windows 10 and WSL have unique ID’s, though the computer name is the same. I didn’t change that however. I did change the port, but that made no difference when trying to launch Syncthing via explorer.exe.

On Windows 10, Syncthing was installed through the exe. On WSL it was installed by adding the Syncthing ppa.

Can you post a full log from the WSL instance of Syncthing, where it complains about itself already running?

I shutdown and restarted WSL so you can see the log upon running Syncthing for the first time. I removed my unique token, the global discovery id, and my IP from the log.

10:13:10 INFO: syncthing v1.19.1 "Fermium Flea" (go1.17.7 linux-amd64) 2022-02-21 13:57:21 U    TC [noupgrade]
10:13:10 INFO: My ID: N-D-Q-J-A-4-Y-6
10:13:11 INFO: Single thread SHA256 performance is 393 MB/s using minio/sha256-simd (391 MB/s using crypto/sha256).
10:13:11 INFO: Hashing performance is 333.61 MB/s
10:13:11 INFO: Overall send rate is unlimited, receive rate is unlimited
10:13:11 INFO: Ready to synchronize "Default Folder" (default) (sendreceive)
10:13:11 INFO: Using discovery mechanism: global discovery server    LYX******
10:13:11 INFO: Using discovery mechanism: global discovery server    =LYX******
10:13:11 INFO: Using discovery mechanism: global discovery server    =LYX******
10:13:11 INFO: Using discovery mechanism: IPv4 local broadcast discovery on port 21027
10:13:11 INFO: Using discovery mechanism: IPv6 local multicast discovery on address [xxxx::****]:21027
10:13:11 INFO: TCP listener ([::]:22000) starting
10:13:11 INFO: Relay listener (dynamic+ starting
10:13:12 INFO: GUI and API listening on
10:13:12 INFO: Access the GUI via the following URL:
10:13:12 INFO: My name is "lv426"
10:13:12 INFO: Completed initial scan of sendreceive folder "Default Folder" (default)
18 2022/04/06 10:13:12 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See for details.
10:13:12 INFO: QUIC listener ([::]:22000) starting
10:13:22 INFO: Detected 0 NAT services
10:13:31 INFO: quic:// detected NAT type: Port restricted NAT
10:13:31 INFO: quic:// resolved external address quic:// (via    78)
10:14:27 INFO: Joined relay relay://

Thanks for the log. It doesn’t show any errors though. According to the log, Syncthing should be up and running, with the GUI available under

Late reply, but I did end up getting this working shortly after my last post.

The problem was both the IP address and the port. I’m not sure if I changed the IP when I was trying different settings in the config file, or something got messed up during reinstalls. The IP should always be set to (localhost). As for the port, 8384 was being used by Windows 10, so Syncthing on WSL needs to be something else. I tried going up a few numbers, but nothing worked. I eventually tried 8399 at random and that worked. The issue was probably just not restarting Syncthing after making so many changes. I did not have to open any ports in my router.

So as of now, running Syncthing on Windows 10 and WSL on the same machine works without issue. The only thing is you need to manually start the Syncthing service on WSL at launch, if you close WSL, or restart the computer. There is some hacky method to install systemd on WSL, allowing Syncthing to run on boot, but I didn’t bother with that.

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