Multiple Send Only Folders Into One

I have around 5 folders on 5 different machines that I want to sync into one on a 6th machine. Each of the 5 machines produce different files daily and do not need to store the files from the rest of the 4 machines. The 6th machine needs to store all of the files combined from all 5 machines. To accomplish this I’ve set shared the required folder with the 6th machine on each of the 5 machines and set them to “Send Only”. On the 6th machine I’ve accepted all 5 shared folders from each of the 5 machines and I’ve entered the same folder as path on each of the 5 shares.

So now all the files from the 5 machines get synced to the 6th machine and are gathered in one place. However I constantly get “Out of Sync” message on each of the 5 machines since they do not own all the files that the 6th machines stores. This seems like a bug in case there is an existing workaround.

How can I avoid this?

This is how Syncthing works, 5 different folders from 5 different machines should go to 5 subfolders. They will always be out of sync when combined into one folder (because the other nodes dont have the others files).

Correct me if I’m wrong.

1 Like

What @jerryjacobs said or if you really want to have all in one directory, you can try to create just one Syncthing folder and on the “non-central” devices ignore everything except what is generated on this device. I however don’t know how well send-only and ignores play together, so no guarantees.

Then you have to manage excludes on all nodes which sync to the central instance. Which makes it easier to have a subfolder per-host.

I’ve imagined it is how it is designed, but I think there should be an option to do this. All 5 non-central devices produce new files in those folders daily with very similar filenames, so there’s no way to set rules to exclude the unnecessary files.

Also I do need all files in one folder in the central device as it is how my software that processes them needs the files.

I know this is not an everyday situation, but since syncthing is already capable of handling this, maybe some changes can be made for setups like this so users can avoid seeing out of sync messages.

Don’t take my word for it, but I suspect the fact that this works is either due to generally robust code or simple luck, I don’t think multiple folders at the same path were intended. Maybe the in-the-making receive-only (aka write-only) folder could be of use for your scenario (central node receive-only, rest either normal or send-only).


The original intention for Syncthing is to bidirectionally sync files between two or more devices sharing a folder.

Over time we’ve accumulated various hacks that break that model in one way or the other - send-only folders, ignores, ignoreDeletes, possibly soon-to-come receive-only folders, etc. They all have various nasty side effects as they to some extent go against Syncthing’s underpinnings.

When you explicitly do not want bidirectionality, and in your case @spiritfly not really peer-to-peer syncing/block sharing either, the better solution is something like an hourly scheduled rsync.

1 Like

Unfortunately these machines are windows so rsync is out of the questions as well :frowning:

Can’t wait for the receive-only folder option, is there any ready beta to test it out yet maybe?

This was the first hit for “rsync for Windows”:

Unlike “rsync”, DeltaCopy is a only available for Windows and is tightly integrated with services available only on Microsoft platforms (XP, 2000, 2003, Vista, Windows 7 & 2008).

Not that I don’t support using Syncthing, but shoehorning it in where it doesn’t naturally fit can be painful.

@spiritfly There is not beta, but if your interested you can follow the progress here:

That’s certainly true, but I suspect many users have joined Syncthing for its ability to “just work”, I know I did. My use-case would probably still be better suited by rsync/unison plus some scripting, but really why bother when syncthing does it as well with small setup effort and many other benefits (minimal work conflict handling, security, …). So I am not saying this should be a reason to start shoehorning in the code (never), but I can understand every user who first tries to shoehorn Syncthing into their requirements before abandoning it.


I already use syncthing on these machines for other syncing tasks and it works marvelously well for some time now. So since I already have it installed I thought why install other software for something that is so similar to what I already do.

While it would be nice to have a couple of different options that open up syncthing for different scenarios, it might be best to keep the code clean as it works so well as it is.