I have a 3 tier setup where I have multiple send only primary servers (we will call them A) syncing to a second receive only server (B). There is a 3rd receive only server (C) that syncs with B. While there are multiple A servers they are each syncing their own folder so a file changed on one A server will never exist on or need to get synced to another A server. All the A servers can communicate with B and B can communicate with C but the C server doesn’t have access to the A servers. Hopefully that all makes sense. My issue is server C shows server B is always out of sync, and when I click to show which files are you of sync the list is empty. The number of files and the size have been constant for several days now.
I have 2 questions.
Are my files actually in sync? I think they are but I would like a way to verify.
How do I get Syncthing to realize everything is in sync?
This picture is from the C server showing the status of the B server
B says C is Up to Date, from all the A’s and B perspective everything in in sync. I’ve also gone through all the individual folders on all servers and they all show as Up to Date. The only place anything shows as our of sync is in the screenshot I provided.
And you are sure that all folders are shared with all other devices?
To me this looks like device X is sharing a folder with device Y, but device Y is not sharing it back.
I’m not sure I’m following you. Let’s simplify this and talk like there is only 1 A server as I don’t think the multiple A servers matter in this case. Server A is send only and shard folders with B. B is receive only and has shared folders with A and C. C is receive only and has shared folders with B. All folders show as shared on both ends between B and C as well as between A and B. Folders are not shared between A and C because A and C can’t communicate with each other. As far as I can tell the actual folders are in sync. It’s almost as if Syncthing thinks there are some ghost files somewhere that it can’t sync. I can play around with servers B and C a little but I hat to make absolutely certain that nothing flows back to server A
Direction of data flow is decided by folder type (with some caveats), not which “direction” the sharing is enabled.
A sharing a folder with B, but B not sharing the folder back with A is simply invalid configuration that leads to things that you see now.
There even should have been a prompt asking for the folders to be shared. The ignore button is purely to combat someone spamming you with requests, not a confirmation of that being a valid configuration.
Sorry I have’t dug into your description in detail, but I hope the above helps
So it would mean that directories on B – and/or subdirectories that are already linked between the A(s) and B – are being re-shared with C (not a supported configuration, but can be done with care).
Because the A(s) are invisible to C, C’s view of the world is whatever files it locally has plus what B says B has.
B could have files it received from the A(s) that it was unable to relay to C, resulting in a difference between B and C (so B is again out-of-sync in C’s eyes), but from the screenshot it doesn’t appear to be the case.
In addition, because it’s a “waterfall” configuration where files only flow from A → B → C and never in the reverse direction, C could have files that B doesn’t have, making B out-of-sync in C’s eyes.
(I understand the need/desire for privacy, but the earlier screenshot was redacted just a tad too much. Try to include as much of Syncthing’s UI as possible and swap in suitable names for folders and such as needed instead of blackouts. It’s also helpful to be able to see not just C’s Syncthing UI, but also B’s. The more information that’s available, the easier it is to zero in on what’s causing an issue.)
Maybe you just need to check the “Ignore permissions” option for the folder on one or several nodes? If it’s trying to sync permissions on a filesystem that doesn’t properly support storing them, that can also lead to permanent out of sync states.
Thanks, the updated screenshots were very helpful.
One thing that stands out is that the difference in the local state file counts for B and C is very close to the number of out-of-sync items: 2,891,662 (C) - 2,206,957 (B) = 684,705
Since the screenshot for C didn’t indicate a warning about local additions, check for permissions issues.
I’ve checked permissions on both ends and the user Syncthing is running as has full control over the folders. Is there a way to see what files it thinks are out of sync? When I click on the Out of sync items on C I get an empty list. Alternatively is there a way to just reset everything? I’d be fine letting it rescan if it got rid of this issue.
If I’m reading the state correctly server C thinks there are ~700K items that need to get sent to server B. That’s why C’s local state has so many more items than B’s local state. Is that the proper reading of the data?
I ran --reset-database, because I was reading the docs before coffee and typed the wrong one. It’s doing a full scan now but it looks like this will fix my issue. I suspect --reset-deltas would have as well with less overhead. In any case once the full scan is done I’ll reply back. I appreciate all the help with this one.
One final reply for anyone who finds this in the future. After running --reset-database the C server identified that it had local changes and asked if I wanted to revert them. Reverting them fixed all the issues I was having.
