Hello everyone,
I’ve been working on setting up a one-way, self-healing sync between two servers and have run into an issue that I can’t solve despite extensive troubleshooting. I’m hoping the community can shed some light on whether this is a known issue or if I’ve missed something subtle.
The Goal
To have a fully automatic, one-way sync from a Source Server to a Remote Server. If a file is deleted on the Remote Server, it should be automatically re-downloaded from the Source without any manual intervention (no buttons to click).
The Environment
-
OS: Both servers are Windows Server 2022.
-
SyncThing Version: v2.0.6
-
Network: Air-gapped internal network. Devices connect directly via FQDN.
-
Setup: SyncThing is running as a service using NSSM under a dedicated service account.
The Problem
When a file is deleted from the sync folder on the Remote (“Receive Only”) Server, the automatic self-healing does not occur. Instead, the GUI on the Remote Server displays a “Revert Local Changes” button. Clicking this button correctly restores the file. New files added to the Source sync perfectly. The issue is isolated to restoring deletions on the Remote server.
Configuration
The configuration appears to be correct for this use case.
Source Server config.xml for the folder:
<folder id="0000" label="SyncTest" path="E:\SyncTest" type="sendonly" rescanIntervalS="3600" fsWatcherEnabled="true" fsWatcherDelayS="10" ignorePerms="true" autoNormalize="true">
<device id="<REMOTE_DEVICE_ID>" introducedBy=""></device>
<!-- ... other settings ... -->
</folder>
Remote Server config.xml for the folder:
<folder id="0000" label="SyncTest" path="E:\SyncTest" type="receiveonly" rescanIntervalS="3600" fsWatcherEnabled="true" fsWatcherDelayS="10" ignorePerms="false" autoNormalize="true">
<device id="<SOURCE_DEVICE_ID>" introducedBy=""></device>
<order>largestFirst</order>
<ignoreDelete>true</ignoreDelete>
<!-- ... other settings ... -->
</folder>
The GUI on the remote server correctly shows the status “Altered by ignoring deletes,” confirming the setting is loaded.
What I’ve Tried (Troubleshooting)
I feel I’ve exhausted all the standard environmental causes:
-
Permissions: Verified with the “Effective Access” tool that the service account has Full Control over the sync folder. Initial sync and new file syncs work, proving basic write permissions are fine.
-
Simple Path: The issue occurs on both a simple local path (
C:\SyncTest) and a DFS path (E:\DFS\...), so it’s not a DFS-specific problem. -
Firewall/Antivirus: There is no third-party AV, and the Windows Firewall has the correct rules. The successful initial sync confirms connectivity is not the issue.
Despite the configuration being what I understand to be correct for self-healing, the manual “Revert Local Changes” step is always required.
Is this a known bug or limitation with SyncThing on Windows Server 2022, or is there another advanced configuration option I might have missed that could be causing this behavior?
L.E.: I’ve read something similar on the forum about using the API to trigger either from the remote server (“Revert Local Changes”) either from the source server (Override Changes), only if the remote server is configured for Send and Receive Only. Does anyone have a procedure how to use that? I can build a script to Invoke RestMethod, but I am concerned about the trigger … how I could detect the change on the remote server to act as a trigger for my script. I could use a scheduled task to poll the changes, but it is not something to my liking and this is why I came to ask the community.
Thanks in advance for any insights!
Cristi
.
Some of the remote clients are disconnected most of the time, but when they connect to the local network, SyncThing detects their presence and the sync starts accordingly.
Until now I like the way it works (without the ignore delete option set), but I wanted to improve it by covering this “accidental intervention” by end users.