Did you ignore permissions on Synology? Permissions are royally borked on Synology so it’s best to ignore there (I am negatively biased towards Synology in general, but I believe that statement is fair).
And out of sync items with nothing displayed in the opened list definitely sounds wrong. Can you post a screenshot for starters.
That is screwed in other ways too: local state is much bigger than global state. What version are you on? Has this folder ever been send-/receive-only? And finally could you post logs please.
Since its creation, this folder at NAS was receive-only with ignore-delete, and its counterpart in the phone was “sent-only”. The synchronization was set up more than a year ago, and was used the way I described in the scenario 1.
That is, new photos were synced from the phone to NAS, and from time to time I moved the synced photos from the Syncthing folder at NAS to a photo folder. From the Syncthing perspective the files were deleted. This worked fine until yesterday, when I changed the unidirectional synchronization to bidirectional. Immediately, the Syncthing folder at NAS became out-of-sync with the problems we’re just talking about. In the phone, however, the folder looks synchronized.
Syncthing at NAS: v1.4.0, Linux (64 bit)
Syncthing at Android: v1.3.4
I’ll try to post the logs in the next post.
After that I suspected that switch to be the cause. However re-reading the OP I see:
Can you confirm that you have reset the db on the NAS after switching the folder to send-receive and the same problem happened again.
Hm, --reset-database doesn’t work, on NAS. I stopped syncthing and executed
./sycthing --reset-database
and syncthing silently exited. I hoped it did its work, but evidently it didn’t. According to Effect of parameter | -reset-database // -reset-deltas, this command should remove the folder /var/packages/syncthing/target/var/index-v0.14.0.db/, but it did not :-(. Can I remove the folder manually?
When I executed
./syncthing --reset-deltas
syncthing started and - according to its log - it performed what it was expected to do.
Is the same problem for all Synology admins. Different threads have as result the same. E.g.
https://forum.syncthing.net/t/panic-non-increasing-sequence/14570
At the end it was for me also the best to stop Syncthing, delete the content of the folder index-v0.14.0.db and start Syncthing again. This I make with all devices, it means Synologys, Windows, so it was clean. Since this point all is running without problems.
Also one productive NAS with Kastelo installation and update from v1.3.4 to now v1.4.0 works without any problems. The migration was without faults.
After deleting the index folder content, the problem hasn’t resolved. In fact, the situation is now even worse.
I’m beginning to panic :-(.
You are seemingly doing random things. I don’t think anyone advised you to reset the database, and you seemingly started inventing your own remedy, which lead you to this.
Are you connected to the remote(s) and has all the activity (scanning syncing) stopped?
Check if they are actually deleted and/or if they differ from the remote.
And please post screenshots again.
@AudriusButkevicius No. In other theads they advise to perform --reset-database which usually resolves all problems. As this command didn’t do anything in my instalation, I did that manually. I was consulting that with @imsodin and @Andy, and they didn’t advise me not to do that. So no random things.
Plenty people struggle - see the forum - with situations when Syncthing gets out-of-sync. In my opinion, there’s missing a comprehensive help that would instruct users what to do when this problem occurs for them. Out-of-sync may occur at various places - at sender or receiver, in folder or device. And all these variants ahould be handled in the help.
True, it’s definitely too omnipresent at the moment. However I did actually ask you whether you did reset the db and when - I did not tell you to do it now. I do however get how you got the impression that it is a good idea to do it now. And it’s not that bad, we can take it from here too.
There’s no comprehensive help other than docs.syncthing.net (which has a lot of useful, but admittedly also some missing/outdated info), because it shouldn’t occur. What we are doing here is debugging a problem, that should lead to finding the bug and fixing it, such that you and everyone else don’t encounter it anymore.
So right now please post the requested information and we will try to figure out what’s going on.
The remote devices connect to NAS every several minutes, they are not connected permanently. While I was deleting the index, Syncthing was stopped, then I started it again, and it automatically started scanning everything. And remote devices started to connect.
The locally changed items do not exist at NAS. Syncthing reports size 0B for some of them, for others it reports its actual size before deleting. These files are not present at the remote device.
For the out-of-sync items I cannot say, as Syncthing doesn’t display the list. But as it displays the total size 0B, I think they are also the deleted files.
Screenshots
The 0 bytes ones are placeholders like .nomedia, they really are 0 bytes. And many of them are hidden files (starting with a dot) - did you check for that? If in doubt post the output of ls -la from one of the paths (e.g. just Helium).
There’s any way something wrong with the out of sync files not being displayed, no idea what from the top of my head. To get an understanding of the actual sync situation, please also post screenshots of the folder from the remote.
In my post at 12:11, in the third point, I said that - after index reset - some of the out-of-thing items moved from the out-of-sync folder to the corresponding device. Actually, these are the files that have been deleted from the remote device (the phone) but remained at NAS. After index reset, NAS wants to synchronize these files back to the phone, but this sync fails due to some problems at the phone side (“Your android version only grants Syncthing readonly access to the folder”, which prevents me to change the folder type to send-receive). Hence, the out-of-sync of this device is an expected behaviour. The phone shows exactly the same number and size of unsynchronized items as NAS.
I have to find a way how to allow write-access for Syncthing in the phone, but I think this is not related to the problems above. (The Android app is given Read/Write access to external storage, but still reports insufficient privileges.)
That doesn’t help, this is a known limitation of android. However I believe your android is set to send-only, so you can press the override button there to force it’s state on the NAS (that will make the NAS identical to the phone, i.e. also delete anything the NAS has but the phone does not).
Yes, it is set to send-only, and due to the problem with privileges, I cannot change that. But I do NOT want to delete the files from NAS! That’s why I originally had the unidirectional sync set with ignore-delete. Now I changed it to bidirectional sync, but again with ignore-delete. I want the photos synced from the phone to remain at NAS until I move them manually out. I do not want the deletion at the phone side (e.g. because of the SD card becomes full) to result in removal of the photos from NAS.
Of course, I can backup the photos for now and perform experiments, but only for a limited time. After resolving the problems I want to return to the described state.
Ignore deletes also works if you click override.
There’s no Override Changes button on either side (not at the NAS side, neither at the phone side).
There’s Revert Local Changes button at the NAS side for the folders in the state Local Additions. Pressing it didn’t result in anything, there are still the same Locally Changed Items as before. There’s nothing in the log about this action.
I am confused: Is that folder now receive-only and has ignore deletes set, and the files shown as locally changed are deleted on the other device? In that case it’s debatable whether those files should be out-of-sync or locally changed, but nevertheless the behaviour is as intended (the files aren’t deleted).