Incomplete synchronization warning of a shared folder between multiple devices.

I have many 1:1 “Send & Receive” shared folders between each single device and a Synology NAS, which work perfectly.

Additionally, on six devices I created a “Send & Receive” folder - many to many - called “SharedSyncthing” shared between the six devices - 3 android, 2 Windows and 1 Synology.

In all six devices, the “SharedSyncthing” folder contains: the .stfolder file, a folder and 5 files. In the folder there are 12 files and .stfolder.

It happens that: Syncthing on the left warns me that the folder is synchronized, but on the right that the synchronization is stuck at 57%.

I have verified that the 16 objects - files and folders are all there, on all devices. Including .stfolder. That is, the synchronization appears complet despite the warning.

I have deleted several times all the folders and files contained by all the devices, I have deleted all the synchronizations, then I have recreated all the objects and all the synchronizations in the same way, but in the end I always have the notice of a synchronization stuck at a certain percentage.

What can be the explanation?

With this mix of different architectures, it is probably a good idea to enable the “ignore permissions” advanced option on the folder. That should make it show a sync status. Especially on Synology devices, checking that option is almost a must.

1 Like

To be honest, I personally always enable “ignore permissions” and set it as default for all folders. We sync mostly Windows and Android, and I’ve never found a use case for having the option not enabled.

In what situation specifically would it be preferable to have the option disabled and actually sync permissions? I’m thinking more of a home/office use case here.

Unix, essentially.

1 Like

Does this include macOS too, or only straight Linux desktop? If yes, will it also work in a mixed Linux/macOS environment? What about Synology and other NAS operating systems? They’re usually Linux-based, but the general recommendation seems to be to always enable the option on them. Should they rather be treated similarly to Android or something like ChromeOS (i.e. running the same kernel, but significantly different in other aspects)?

Also, does this mean that the option is useless on Windows then?

That’s a lot of questions. Syncing permissions is useful when the permissions are useful. How that applies to your systems is up to them and you…

Yeah, I know there were quite a few questions asked in the short paragraph, but I think the problem is that the option doesn’t seem to be explained in detail anywhere (except for the Web GUI itself and the short description in the Docs at with a few examples about where not to use it, yet limited to filesystems only, and no explanation on how it affects syncing between different operating systems).

The reason for asking all this is that the option is on by default, yet disabling it seems to come up on forum a lot as the ultimate solution to “out of sync” issues, especially when NAS systems are involved. As far as my current understanding goes, it appears that it should always be disabled when syncing includes non-Unix operating systems, as the whole permission system is incompatible between the two.

The incompatibility is handled as far as I know (example comes that showes otherwise). What likely doesn’t work is applying the permissions on those systems, which then makes it out of sync. The one thing I see that could be done is to have a special errors for these cases indicating the permissions are the problem, and linking to the ignore permission setting - something like this.

I mean it’s not that complicated. The permission bits are a single integer, and on unixes they generally make sense to sync for several reasons. On windows most bits are ignored except the ones that mean read only.

NASes, however, almost universally invent their own system on top with ACLs and odd filesystem shims, so who knows what happens with permissions.

Thank you very much for a simple and clear explanation! Now I think I finally understand what syncing permissions really means :slightly_smiling_face:.

It would be great if that information was included in the Docs, although I’m not sure where exactly it should be placed, as it’s not really about the ignorePerms config option, but rather about explaining how syncing permissions works in general, and what kind of permissions are synced depending on the OS…

I confirm - for what it’s worth - that by enabling the “Ignore permissions” function (nested in Actions (top right)> Settings> General> Default configuration> click on> Change folder defaults> Advanced> flag on “Ignore permissions” (here) the synchronization proceeds and completes successfully between different OSes: Windows android and DSM7 (or later) Synology. Setting not very easy to find, but effective and working. Synchronizations that were not initially completed have all been successful.


Those who read and were able to intervene in the Syncthing update, could consider inserting a switch in Actions> Settings> Ignored folders - to delete - intentionally - folders created by mistake and deleted and / or replaced in the device / s. I think it is useless, especially after some time, to keep the evidence of objects that no longer exist, perhaps creating doubts or confusion

P.S. In my opinion - especially for the feature that enriches and distinguishes Syncthing, that is the inter-operability between different O.S. - the “Ignore permissions” function is hardly highlighted. In addition to being difficult to apply because it is difficult to find.

Well that setting for the “Folder Defaults” configuration only applies for newly added folders. For existing ones, you just need to switch to the “Advanced” tab in the dialog that appears on “Edit” under the folder details. Same for new folders being added. That’s more discoverable hopefully. And in your case, it’s what will help with existing folders as well.

1 Like

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