I have a PC running Windows 10 and a Synology NAS. Both with Syncthing 0.14.43-rc.1.
I used to have all files in sync. I moved the hard drive from one PC onto the new Windows 10 PC.
I can see, I think, that newer files since the move are syncing correctly, which is good. However, I have 117008 (43.4GiB) items out of sync. See here https://i.imgur.com/rgaSONM.png
I’ve looked in the forums and can see this topic mentioned right back to 2015, but can see the topics don’t get resolved - first topic points to the next one, the next one is getting somewhere but bottom says “moving this to a new topic” which isn’t linked, and then others that are commented but not resolved and then closed.
When I click on the items, the file list changes each time (despite choosing Newest First and the total number of un-sync’d items always being the same number) and they all say “Sync”
Oh and remote device says “Up to date”
So something’s awry somewhere. Firstly, the data on screen doesn’t match, and secondly the files left to sync are not progressing.
Everything looks ok to me. Syncthing is still receiving the list of files that need syncing from the remote peer, and it should be syncing them as displayed in the folder status.
The remote device is up to date as from this devices perspective, the remote device has all of the latest files (and is supplying them back to you).
What on screen data does not match? Local state numbers being equal to global ones doesn’t mean there is nothing out of sync (modifications).
Just to clarify: The syncing percentage and number of out of sync items does not decrease in time? That would be bad indeed (as in they should then show up as failed items) - check the logs, which you can now also do in the web UI by going to Actions → Logs
Just a quick reply before I check logs … sure, not clear re “data on screen” - I meant that oe part says thousands of files out of sync, and the other part says “Up to date”.
And Audrius - sure, the sync has recognised that there are thousands of files to sync, but that same number and GiB to sync has been like that for 2+ weeks.
OK, one more from me. I can see log entries on the Windows PC as follows, but nothing to do with file syncing - should I enable some specific logging?
2018-01-04 11:09:55 Listening for UPnP response for device type urn:schemas-upnp-org:device:InternetGatewayDevice:2 on Loopback Pseudo-Interface 1
2018-01-04 11:09:55 Sending search request for device type urn:schemas-upnp-org:device:InternetGatewayDevice:1 on Loopback Pseudo-Interface 1
2018-01-04 11:09:55 Listening for UPnP response for device type urn:schemas-upnp-org:device:InternetGatewayDevice:1 on Loopback Pseudo-Interface 1
2018-01-04 11:09:55 Discovered gateway at 172.31.1.254
2018-01-04 11:10:05 Discovery for device type urn:schemas-upnp-org:device:InternetGatewayDevice:2 on Ethernet finished.
2018-01-04 11:10:05 Discovery for device type urn:schemas-upnp-org:device:InternetGatewayDevice:1 on Ethernet finished.
2018-01-04 11:10:05 Discovery for device type urn:schemas-upnp-org:device:InternetGatewayDevice:2 on Loopback Pseudo-Interface 1 finished.
2018-01-04 11:10:05 Discovery for device type urn:schemas-upnp-org:device:InternetGatewayDevice:1 on Loopback Pseudo-Interface 1 finished.
2018-01-04 11:10:05 Timeout trying to get external address, assume no NAT-PMP available
It’s in the advanced settings menu, but if you don’t know about it’s unlikely that’s the cause. Can you restart with STTRACE=model env var and provide the log from stdout after a few minutes and report if it still shows up after restart?
Also, does the device look like it’s out of sync on the remote end?
@calmh this could be your metadata cache issue right?
So I’ve set the STTRACE model and the STDBCHECKEVERY env variables and restarted syncthing on the PC (don’t know how to do this on the Synology NAS, so thought I’d try just this first).
This is the stuff i’m seeing:
2018-01-04 15:29:16 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:29:16 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 53.871160267s
2018-01-04 15:29:38 model@0xc04219e360 IDXUP(in): DFXNXN3-WY2XTYG-UZP6O7B-CAOJCGM-FHZJ52E-6SYBYFV-W56QLBY-SS6A4A6 / "tcp7k-dhkkq": 2 files
2018-01-04 15:29:38 sendReceiveFolder/tcp7k-dhkkq@0xc0421a0900 pulling (ignoresChanged=false)
2018-01-04 15:29:38 sendReceiveFolder/tcp7k-dhkkq@0xc0421a0900 c 2 p 64
2018-01-04 15:29:39 sendReceiveFolder/tcp7k-dhkkq@0xc0421a0900 changed 0
2018-01-04 15:29:40 progress emitter: bytes completed for tcp7k-dhkkq: 0
2018-01-04 15:29:40 model@0xc04219e360 NeedSize("tcp7k-dhkkq"): {0 0 0 0 0 0 []}
2018-01-04 15:29:42 model@0xc04219e360 Completion(DFXNXN3-WY2XTYG-UZP6O7B-CAOJCGM-FHZJ52E-6SYBYFV-W56QLBY-SS6A4A6, "tcp7k-dhkkq"): 90.269790 (46527856687 / 478179359557 = 0.097302)
2018-01-04 15:30:03 sendReceiveFolder/Sage@0xc0421a0b40 Scanning subdirectories
2018-01-04 15:30:03 &{60000000000 0xc043d92200 0xc042ae2ae0 0xc042ae2b40} next rescan in 47.380147576s
2018-01-04 15:30:09 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:30:09 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 46.357303002s
2018-01-04 15:30:14 Sent usage report (version 3)
2018-01-04 15:30:20 sendReceiveFolder/tcp7k-dhkkq@0xc0421a0900 Scanning subdirectories
2018-01-04 15:30:51 sendReceiveFolder/Sage@0xc0421a0b40 Scanning subdirectories
2018-01-04 15:30:52 &{60000000000 0xc043d92200 0xc042ae2ae0 0xc042ae2b40} next rescan in 1m7.509460321s
2018-01-04 15:30:56 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:30:56 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 58.981721337s
2018-01-04 15:31:22 &{60000000000 0xc043d92080 0xc042ae2840 0xc042ae28a0} next rescan in 1m2.883236728s
2018-01-04 15:31:55 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:31:55 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 45.390832774s
2018-01-04 15:31:59 sendReceiveFolder/Sage@0xc0421a0b40 Scanning subdirectories
2018-01-04 15:32:00 &{60000000000 0xc043d92200 0xc042ae2ae0 0xc042ae2b40} next rescan in 1m0.349090574s
2018-01-04 15:32:25 sendReceiveFolder/tcp7k-dhkkq@0xc0421a0900 Scanning subdirectories
2018-01-04 15:32:40 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:32:40 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 55.327582167s
2018-01-04 15:33:00 sendReceiveFolder/Sage@0xc0421a0b40 Scanning subdirectories
2018-01-04 15:33:01 &{60000000000 0xc043d92200 0xc042ae2ae0 0xc042ae2b40} next rescan in 57.118014896s
2018-01-04 15:33:26 &{60000000000 0xc043d92080 0xc042ae2840 0xc042ae28a0} next rescan in 1m4.785675524s
2018-01-04 15:33:35 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:33:35 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 1m7.679960444s
2018-01-04 15:33:58 sendReceiveFolder/Sage@0xc0421a0b40 Scanning subdirectories
2018-01-04 15:33:59 &{60000000000 0xc043d92200 0xc042ae2ae0 0xc042ae2b40} next rescan in 45.942168954s
2018-01-04 15:34:31 sendReceiveFolder/tcp7k-dhkkq@0xc0421a0900 Scanning subdirectories
2018-01-04 15:34:43 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:34:43 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 51.348435777s
2018-01-04 15:34:45 sendReceiveFolder/Sage@0xc0421a0b40 Scanning subdirectories
2018-01-04 15:34:46 &{60000000000 0xc043d92200 0xc042ae2ae0 0xc042ae2b40} next rescan in 45.869228277s
2018-01-04 15:35:32 sendReceiveFolder/Sage@0xc0421a0b40 Scanning subdirectories
2018-01-04 15:35:32 &{60000000000 0xc043d92080 0xc042ae2840 0xc042ae28a0} next rescan in 55.814961257s
2018-01-04 15:35:33 &{60000000000 0xc043d92200 0xc042ae2ae0 0xc042ae2b40} next rescan in 1m9.672389484s
2018-01-04 15:35:35 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:35:35 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 49.046218202s
2018-01-04 15:36:24 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:36:24 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 59.534038224s
2018-01-04 15:36:28 sendReceiveFolder/tcp7k-dhkkq@0xc0421a0900 Scanning subdirectories
2018-01-04 15:36:42 sendReceiveFolder/Sage@0xc0421a0b40 Scanning subdirectories
2018-01-04 15:36:43 &{60000000000 0xc043d92200 0xc042ae2ae0 0xc042ae2b40} next rescan in 1m2.333925938s
2018-01-04 15:37:23 sendReceiveFolder/default@0xc0421a06c0 Scanning subdirectories
2018-01-04 15:37:23 &{60000000000 0xc042033f40 0xc042ae25a0 0xc042ae2600} next rescan in 1m5.655531055s
2018-01-04 15:37:29 &{60000000000 0xc043d92080 0xc042ae2840 0xc042ae28a0} next rescan in 1m11.379749342s
2018-01-04 15:37:46 sendReceiveFolder/Sage@0xc0421a0b40 Scanning subdirectories
2018-01-04 15:37:47 &{60000000000 0xc043d92200 0xc042ae2ae0 0xc042ae2b40} next rescan in 53.698952533s
I also see a few entries for files that are new and changing right now on the PC side - I know the files are being worked on now, so are totally new. I didn’t post those as they contain quite a bit of confidential data.
Should I now remove that STDBCHECKEVERY environment variable?
Do I also need to set these two variables on the NAS drive somehow for this to work?
So, that’s from the other side compared to the screenshot you posted first? Seems consistent. The device that has the files out of sync should be the one to know why are they are not getting updated.
OK … sorry, so what should I do next? Is there something I’ve done wrong? Or something wrong with the software? (in terms of the same number of files never showing as synced)
Open up the gui on the device where the files are out of sync. Wait at least a minute. Hopefully, under the “out of sync” line there will pop up another one with “failed items” that you can click on and get details on why they are not syncing.
@imsodin or is the pulling too seldom now for that to happen…? Hmm.
Or maybe pull up the logs on that one, like you did here, but without trace options and stuff. Looks for something like mentions the files in question and anything that sounds like an error.
@marky_uk You can pause and restart the folder, that will cause a pull and thus an error event and relevant model logging.
@calmh Pulls due to errors can happen as rarely as every 1h - so that can be an issue. I didn’t consider that the web UI is dependent on frequent error events - errors should probably be part of the folder summary and enter the UI that way.
Now I’m home (where the NAS is, for some reason I couldn’t access the GUI remotely all day) I’m seeing this, now I’ve enabled model logging, and then paused and restarted the sync folder -
Just to be sure: We need logs from the device where the folder is stuck syncing. What I would expect are “Folder label (id) isn’t making progress” messages. Or just post everything that comes up after pause/resume of the folder.
EDIT: Sorry, forgot to answer your explicit question: That log excerpt isn’t helpful unfortunately.
There’s hundreds of them. Not sure why, as I set ownership of all folders under LogicSpot for the sc-syncthing user on the Synology NAS … but hey, that’s another problem if you could answer my question first