All of a sudden lots of sync-conflicts

Since a few days ago, when I change a file on my PC, instead of propagating changes to my other servers (I run a number of syncthing servers), syncthing creates a conflict on my PC, with the ID of my PC instance of syncthing. If I work on a file for a while, I am getting one sync conflict for each time I save the file.

Initially I thought this was because one of my servers is on v1.22.1-rc.1, but I put back all servers on v1.22.0, (Linux or Windows), and the problem persists.

It seems that the conflict arises on a specific LINUX server (I’ve stopped the folder on that server and the problem went away, i.e. all other servers behave correctly), but I am not sure why, since the only agent that can change files in that server is syncthing itself. It seems that instead of applying the change from my PC, syncthing creates a sync conflict, even when it’s rather improbable that the file was modified outside of syncthing.

I would rehash and recreate the database in that server, but I am not sure if this makes the problem go away, and given the amount of files sync-ed it would take a day or so.

Any light anyone could offer?


Came to the forums just to ask the same thing. I have folders that are synced to and between two servers, but files are created and changed only on one client. No application other than syncthing itself has had access to any version of the files on any computer other than this one client. Still, almost universally every time I edit a file, say a text file using Notepad, the previous version pops up alongside the newly edited one as a conflict file.

Both servers are using Syncthing 1.22.0 on Linux (TrueNAS Scale), client is using Syncthing 1.22.0 on Windows (with SyncTrayzor).

1 Like

There is a known bug in v1.22.0 that can cause such conflicts to appear (please search for “conflicts” on the forum and GitHub, as there have been quite a few topics about the issue recently).

The fix is already included in the current release candidate, so if you upgrade all your devices to that, the problem should be gone. Alternatively, downgrading to v1.21.0 is also an option, but it can be tricky in this case due to a config version change, so please try this only if you know 100% what you’re doing.


Thank you! Apologies, I searched for “conflicts” before posting to the support forum, I got results from years ago. I don’t know why I never get the right results.


Yeah, you need to sort the results “by date” to get anything useful. Otherwise, topics from a few years back seem to come up first for some reason.

1 Like

There’s some improvement, but I’m still getting a lot of sync-conflict files after upgrading my cluster to 1.22.1-rc2. I’ll add a note on github.

I’m not sure which Github bug to file this under. Any suggestions? I’m getting sync conflicts all day long from other servers in a cluster that never touch the files.

Can you provide more details on what is happening exactly? What kind of devices and operating systems are involved? Are all devices running 1.22.1-rc2? That bug itself should have been fixed in 1.22.1-rc2 completely, so maybe there this is something else.

Can you track down which device causes the conflicts specifically? Even the “Recent Changes” in the GUI should be enough to show who is responsible for file modifications.

Server A is Centos 7 with Syncthing v1.22.1-rc.2, Linux (64-bit Intel/AMD), and the source for all actual changes. The Send-only folder pairs are the ones showing all the conflicts (“Out of Sync” & “Override Changes”). I do not find any sync-conflict files on this server.

Servers B and O are FreeBSD 12, Syncthing v1.22.1-rc.2, FreeBSD (64-bit Intel/AMD) replicas for disaster recovery (in-depth backup is handled elsewhere).

Per the “Recent Changes”, all the conflicts appear to come from Server B, which has a UFS file system. Modifications on “B” seem to take place within a minute or two of receiving a new or changed file from the cluster, which originates on Server A.

Server O has a ZFS file system and does not seem to be creating conflict files, or at least not at the same rate as Server B. (ZFS also seemed to be less affected than UFS with the kqueue issue I raised between 1.19 and 1.20.)

The sync-conflict files with the Server A device ID show up in both the folders and the .stversions directory of both Server B and O.

I also sync a couple of the same folder pairs to my Windows 10 workstation [v1.22.1-rc.2, Windows (64-bit Intel/AMD)], and I regularly find sync-conflict files there with the device ID of Server A. None of those files are changed on my workstation.

Per Understanding Synchronization — Syncthing v1.22.0 documentation, “Conflicting Changes”, the “modified by” device ID for all the sync-conflict files in the cluster are from Server A.

Since the folders on Server A are Send-Only, the sync-conflict files only show up in the receiving nodes of the cluster; most on Server B and only a few on Server O.

@calmh @tomasz86 Do you have any suggestions on which Github issue I should report this under? Or should I start a new issue?

If you want to report the issue on GitHub, please make sure to either a) provide detailed steps that anyone can follow to reproduce the problem, or b) provide debug logs from your setup. If you go with b), the standard procedure is to enable db and model debugging, then reproduce the problem on your device(s), then attach full logs to the GitHub issue.

Please be aware though that the logs will contain a variety of information, including filenames and such. Also, if you want to save the logs to the disk for debugging, you should run Syncthing with the --logfile option (see

1 Like

I actually tried v1.21.0 via Synctrazor but still conflicts are generated :frowning:

I am also having this issue on Syntching 1.22.1. I am editing the file on one computer and syncthing syncs a bunch of conflicts. For example, I edited a markdown file and added 6 words, but it generates 6 conflicted copies from the same device (a Windows 11 PC).


1 Like

I’ve noticed the same thing (in my case when a file is edited on Linux): the sync-conflict files have the identifier of the Linux machine on which I did the edit.

I did not experience sync conflicts before the 1.22.1 release, so I don’t know if that identifier being the same is normal or not.

I just tried a test where I edited a file on Linux, saved it, and watched what happened on Android.

I saw a “.tmp” file get created on Android (usually a bad sign) which turned into a sync-conflict file a couple of minutes later, and then got sync’d back to Linux.

Since upgrading everything to 1.22.2-rc.2, spurious sync-conflicts have disappeared, including some that have bugged me for several years between Centos and SyncTrayzor!

The only place I still have trouble with is one remote machine that is on stable release. But I only have to put up with it for another few weeks until the -rc.2 becomes the next stable release.

Thanks for the fixes!

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