Clients reporting different sync states?

[nle]

Hi all, I’ve been using Syncthing for about a year without issues, but now I got an issue. I’ll explain below.

Syncthing setup:
3 clients:

• 2 x macos
• 1 x linux (“master”)

Syncing one directory called sync (basically using syncthing as dropbox)

What I did:
I recently needed to recreate my ZFS pool on my NAS (due to 512 / 4k sector sizes, etc.). Anyhow. I moved off all the files from the share with rsync (keeping all properties i.e creation, modificaton, etc.), recreated the ZFS filesystem I’m using for syncthing and moved all files back with rsync.

Issue:
I’m now getting different sync states from different clients. My linux client (“master” with simple versioning) is reporting that my two macos clients is at 77%, while my two macos clients (no versioning) is reporting my linux client to be at 99%.

The linux client has the files on a NFS share with full read/write/modify rights.

Any input on how to resolve this?

(See attached image, and please let me know if you need any more info)

(I had to combine the two screenshots due to not being allowed to upload more than one image)

[imsodin (Simon)]

The most important indication is the folder sync state, which isn’t just out-of-sync, it even has failed items in your case. Click on the count of failed items to get a list of affected items and reasons why the fail. If you can resolve that, then see what happens, if you can’t, please post the failure reasons.

Also the linux client seems to be in a suboptimal state (lots of out of sync items, incorrect remote completion) without having any cpu usage -> check Syncthing logs and IO load for anything out of the ordinary.

[nle]

Thank you. It looks to be a permission issue of some sorts. I’ll see if I can figure it out.

[nle]

I managed to resolve the failed list, or that who had the permission errors. But it does not seem to update the sync state.

Is there anyway to resolve this? Or is it faster to just remove the linux client, delete the files, and re-add (i.e let i download form the other clients)?

Current status linux:

[AudriusButkevicius]

You still have failed items… Rinse and repeat.

[nle]

Does a couple of failed items halt everything?

This is the two failed items:

[AudriusButkevicius]

Well you said its at 99%, so its possible that those two items is the missing percent.

[nle]

Not exactly.

Two of the clients says the linux client is at 99%, while the linux client says the two others is at 77%. See the first screenshot.

[AudriusButkevicius]

That is weird but I suspect it will fix itself once you fix those two items. It looks like the two items seems to trigger an issue with reporting.

@calmh @imsodin it seems local state is used to compute remote completion? Atleast looking at the screenshots it seems the remote peers are as out of sync as much as the local device? Perhaps the flags change is triggering something related to ignored items?

[imsodin (Simon)]

No, failed items should not halt the rest. CPU util of 22% suggest that something is happening - is the number of out of sync items decreasing?

The remote completion is based on file infos we receive from other devices compared to the global file info. Ignore patterns shouldn’t matter, as in ignored items are accounted for and don’t appear as out of sync on remotes. However, the recurring reports do suggest that something is fishy, I just don’t have any idea yet what.

[AudriusButkevicius]

The local out of sync and remote out of sync are of pretty much the same size which is why I am raising eyebrows.

[nle]

Thanks for all the replies.

I was not able to sort out the issue, even when removing files it still did not seem to work. I tried rescanning and restarting syncthing several times.

In the end I just removed the whole thing from my Linux client, readded and resynced. It worked fine, and all is synced now.

I guess the only thing I lost is the versioning of the files (that I only have on on the linux client). But in this case, that is no biggie.