It didn’t take very long until similar issues re-appeared.
I originally suspected the Windows machines (and I still do, to a minor part), but the main problem seems to be related to synchronization via SC’s encrypted storage.
Currently, it looks like this on my local machine:
Note that 2 machines with the same share that I’m connected with, rightfully report that everything is synced as it should be. Only the encrypted central sync node shows 92 % and 677 MB left.
On our encrypted central sync node it looks as follows:
So, the central node sees the same 92 % for all nodes, but “thinks” about itself that it is up-to-date as well.
The main issue is that there is not a single button for override etc., so all nodes act as if everything is OK, although showing incomplete sync statuses that never resolve.
Any helpful advice on debugging this issue or developing a viable workaround highly appreciated, I simply cannot find the root cause of this weirdness.
hi
as you’re talking about poisoning by a windows machine, it may be the same problem as the one I’ve just encountered.( Multiple and sudden sync errors on a member. - #3 by skssyncth94 )
What are the versions of syncthing on the different machines? If it matches (and even if it doesn’t), I’d advise you to remove the passwords if you’ve used them in the shares.
We’re not talking about this kind of “poisoning”. I’ve excluded the problematic Windows machine, but the errors persisted and even became worse.
As I have outlined, it seems to be related to the untrusted device feature and how it handles sync status.
I have - once again - “fixed” that issue by removing the encrypted data and all caches/indices of Syncthing from the central machine and re-uploading all files to it, again.
As long as nobody knows how to tackle this issue, I will have to repeat that procedure from time to time, it seems…
