Device won't sync


(Delta Z) #1

I have 2 hosts syncing folders with Syncthing v0.14.52: master Windows 10 system with Send-Only folders slave Ubuntu 18.10 system with Receive-Only folders

At first my problem was that I have deleted some files from the folder on the master, but Syncthing won’t delete them from the slave. This issue only affected some of the files, syncing other files in that folder worked normally.

On the master SyncTrazor I saw that the slave is “Syncing 95% 0 bytes”, and it showed “Out of Sync Items | 15 items, ~0 B” the files that I deleted as modified on the master.

On the slave Syncthing-GTK in the folder view it indeed showed that the local state had more files and more GB, but the status was “synced” with a permanent error “Puller: … delete file : file modified but not rescanned; will try again later”. Those messages repeated in the log many times.

Hitting rescan on master and slave did not help.

This is the second time I encountered this issue, last time I just went ahead and deleted the files on the slave manually, which resolved the problem. This time I decided to try removing the folder from slave and adding it back. The result is that after a re-scan all my folders now show “up to date” on both devices, but the mismatched files on the slave are still not deleted, and the master now shows that the slave “Syncing 69% 100 GiB with 200+ out of sync items” but neither the master nor the slave appear to be doing anything and there is no traffic. :frowning_face:


(Audrius Butkevicius) #2

Screenshots from both sides would help. Also, suggest you check other simillar posts on the forum.


(Catfriend1) #3

We’ve already had that, it’s the ignore perms bug that came with 14.51 and is expected to be solved with the next release. See https://forum.syncthing.net/t/delete-file-file-modified-but-not-rescanned-will-try-again-later


(Delta Z) #4

@Catfriend1 Thanks! I did not notice anything similar searching open bugs will try the forum as well later. I indeed remember messing with ignore perms settings. Will wait for 53 then.


(Delta Z) #5

OK so I updated both clients to .54, but nothing changed.

Any ideas what to do next?


(Simon) #6

There are no puller errors?


(Delta Z) #7

Since I removed the folder and added it back I don’t see anything interesting in the log viewer. Is there a log file I can check?


(Audrius Butkevicius) #8

The web ui exposes the logs. I have no clue where syncthing-gtk exposes the logs.

The thing that catches my eye is differing folder count between devices. Check that one side is not sharing 6 folders with someone who has only 5 folders, making all items in the 6th folder out of sync as the other device does not have them.


(Delta Z) #9

The number of folders is different because there is one folder that I do not share with that specific device. There is no indication of errors in the logs on either side now. I am just going to assume that the state is corrupted somehow and will try re-installing.


(Delta Z) #10

I tried removing and adding back the folder first on the slave and then on the master as well, and in both cases got back to the same problematic state. After I did it on the master I saw in the logs:

[YY4YL] 11:22:53 INFO: Device OL72FVZ folder "Downloads" (Downloads) has a new index ID (0x18C5F03C6D6C8C82)
[YY4YL] 11:22:53 INFO: Device OL72FVZ folder "Downloads" (Downloads) has mismatching index ID for us (0x7853624CD1EAF0FB != 0xB23756F55EDF524F)

Which I assume could be the cause of this problem? How can I completely reset the state for this folder?

P.S.

As I was trying to stop the devices from sharing folders with each other it was a complete chaos for a while.

I unshared all the folders by “Editing” the NUC device from Sync Trazor and then went and removed all shared folders in syncthing-gtk on the other side as well. Somehow I then received a notification on the NUC that the Windows device wants to share all those folders with it again, which I had to “ignore” twice - once in synchting-gtk and once in the Web UI.

One of the above folders is shared with my phone in addition to the NUC and it somehow kept re-sharing itself with NUC twice before I managed to stop it from reappearing. On the NUC I even got “Error: folder marker missing” for that folder although I have removed it from the database completely.

The devices keep disconnecting from each other every time I make a change to the folder list with “Failed to exchange Hello messages with … EOF” or “Connection to … closed: reading length: read tcp …: use of closed network connection”


(Audrius Butkevicius) #11

Making changes to folders requires a reconnect usually.

The index id mismatch is expected if you added and removed folders.


(Simon) #12

What’s confusing me is that there are two logs regarding index IDs, once that there is a new ID and once that the ID is mismatching - with three different IDs. That seems wrong, or am I missing something?


(Delta Z) #13

So what can I do to completely reset the state here and start with a clean slate for that folder?


(Simon) #14

Complete reset means remove the folder (or the entire db) on all connected devices at the same time.