I appreciate the too many open files issue will return through downgrading - but my rationale was: all through the debugging process whilst running of 0.14.41, there wasn’t a problem with this. Perhaps something else in the change from 0.14.41 → 0.14.44 has broken it - and this would be a quick’n’easy way to check (subject to downgrade compatibility).
Ok. The first sync has (I believe) nearly finished - NAS01 says it’s only 29GB out now, but it’s doing a rescan due to a power cut over the weekend. I expect the scan will finish later today / some time tomorrow, so I’ll report back with news then.
…but the display of out of sync items didn’t seem to count down as a result of this. Looking back through the log, I can’t see any instances of ‘update file’ for the last week now.
I also got a bunch of these during the flurry of activity:
The number of files (and size) of the Out of Sync Items isn’t going down - but every time I open the view on this, I’m seeing different files listed in the first page (and the same number of pages available to view each time).
Whilst all this is going on on NAS01, I’m not seeing anything interesting happening on NAS02 (just periodic NAT port remapping and listen address resolution changes, and badgering NAS01 for file/path/1/.DS_Store).
No errors reported on the UI - and obviously a huge bunch of stuff in the logs at the moment (model trace is currently enabled).
There shouldn’t be any issues here - the syncthing group has R/W permission over the entire shared folder, and Ignore Permissions is enabled (on both ends).
You should disable verbose/debug logging and just post the whole log, as this spoon feeding is getting us nowhere, as I suspect you are missing the relevant messages among the verbose debugging cruft.
I assume resource usage on NAS01 is high? I believe it is still reconciling “internal” conflicts. I call them “internal” because they are treated like conflicts, because both devices independently found the files, but as there is no actual difference there are no conflict copies (that’s probably the “metadata file” in one log). That should however finish in a single pull.
You could grep the log for "INFO:.* Puller (folder " to see what errors were encountered before (as there are none anymore in the GUI). Maybe there is a clue there. We should probably expand that logging line to “Puller error (folder…” to make it easier to search.
The problem is that the logs contain sensitive data and are huge anyway, that’s why it was previously uploaded to calmh’s FTP (and he seems to be a bit occupied with non-Syncthing life at the moment )
Currently running at 8% - so not maxing out at all!
The data set is hardly changing at the moment - and it’s had nearly two weeks on the 0.14.44 build to settle down.
I searched for puller (folder - with no results found.
I’m happy to post the full logs to a Google Drive link for you both to look at, if that would be helpful. Which makes me think: Feature Request to obfuscate personal data from logs - would that be worthwhile?
I think I have some good news: I haven’t touched the installation but, since my last update, NAS02 seems to now be pulling files and recognises that it’s 88000 files out of sync.
The Global States still don’t match between the units, but hopefully this is something which will now just work itself out.
Many many many thanks for your input - I really appreciate it, and feel guilty that I might have wasted your time and attention!
Great news! No need to feel guilty at all, it’s not like you force anyone to invest time and time invested on your reports definitely wasn’t wasted - the sparse too many files issue calmh uncovered with your logs was nasty. So quite the contrary, having users like you that go through lengthy debugging and provide necessary information are valuable to the project - thanks a lot!