The problem I’m experiencing is no matter how I create my plain text (*.txt) files, or modify them, I get sync conflicts about 75% of the time.
The ‘hub’ is a TrueNas server running the official syncthing container: v1.29.7.
My 3 other devices are:
Ubuntu 24.04 Desktop: v1.29.7
Android running SyncThing Fork: v1.29.4
M3 MacBook Air (2024): 1.29.7
To recreate the issue I simply create a new .txt file, populate it with some text, and them I’ll usually see it show up as a sync conflict immediately. Sometimes it does go through to all devices successfully however.
I don’t understand how a new file, which doesn’t exist anywhere else other than on the device I created it on can get a sync conflict?
I’ve attached a screenshot of the web interface of the ‘hub’ server.
I know there’s plenty of logging I can enable to assist with the debugging here, so if someone can let me know what needs to be turned on I’ll be happy to send over the logs.
Hello,
one way to understand this better could be to go to the action/protocol section in the web gui before you create the text file. Maybe it shows something about the conflict during creation of the text file.
I wonder if two of the devices are immediately modifying some metadata of the file as soon as they receive it and then re-sending them back to the truenas box at the same time.
So I’ve been doing some digging / playing around, and the issue seems to be caused by ‘Ignore Permissions’ being set to ‘OFF’ on the ‘hub’ server.
Setting the value to ‘ON’ seems to fix the issue.
Can someone explain why this is? I understand that on Android devices this should be enabled because FAT sucks, but my other devices use ‘proper’ filesystems, like EXT4 and APFS.
Could it be something to do with ZFS and ACL’s on TrueNas?
I haven’t got enough knowledge to provide a proper, technical answer, but in general, judging by many support topics on the forum, “ignore permissions” indeed does need to be enabled on the NAS operating systems.
If it fails to set permissions it will indeed fail the sync, unless ignore-permissions is set. What sometimes happens though is that the filesystem lies and accepts the call to set permissions, then forgets them (e.g. FAT on Linux does this). It even fools our attempts to detect this by reading back metadata, because it will respond with the permissions and modification time we set, for a while, because it cached it. Then later it will forget the data in the cache and respond with a different set of permissions and another modification time… In any case, a permission-only difference doesn’t generate a sync conflict, the contents need to differ for that to happen…
However, it can result in a conflict on the next change, when Syncthing compares the file before replacing it and sees that it is not as expected (metadata/permissions differ) and also doesn’t have the same contents as the new file (so a conflict copy is called for).
However, it can result in a conflict on the next change, when Syncthing compares the file before replacing it and sees that it is not as expected (metadata/permissions differ) and also doesn’t have the same contents as the new file (so a conflict copy is called for).
Hmm, I wonder if what’s happening then is I create the file, it gets pushed out to my other devices with whatever contents it has (Or maybe it’s empty if I’ve not populated it yet) and then on the next sync when the content has changed that’s what causes the conflict? ie; the contents have now changed AND something funky is going on with permissions?
Do you think this could be it?
If so, I wonder if this is being caused by the fact the ZFS dataset my Syncthing data lives on in TrueNas uses ACL’s, rather than plain UNIX permissions? Would ACL’s cause an issue in Syncthing?
In any case, a permission-only difference doesn’t generate a sync conflict, the contents need to differ for that to happen…