I’ve made a fresh setup with two new devices (separate to my last topic) with Linux amd64 Syncthing v1.3.3 and got stuck again with no progress while local network connection is running fine.
Device A - has the “master” data which should be copied over to device B which initially had an empty, fresh syncthing folder.
I did not disconnect network or the USB source device. I’ve verified the files can be read properly on the source. Anything I could offer here to diagnose it further?
I’ve never had such problems with Syncthing picking me one after another, so I wonder what or if me has caused this unintenionally??? It just ever ran fine before in every constellation and now - where I need it to copy over a set of regular directories and files - it fails unexpectedly.
Thanks for your patience and help. If required, I come back with more log information. Will let this second “test case” sit as it is if we need it for further diagnosis. (The first I’ve posted before is needed in production).
In your second image for device B I can see for “Letzte Änderung” the deleted “.stfolder”. If this is deleted in real, is clear that this peer can not run. In both peer folders this foldermarker must be available.
Yeah I knew that, but the source files are a backup of my old server and I cleaned the .stfolder from all subfolders, not the main folder. In general you are right, but my main folder still has .stfolder in place :-). You would also get the folder marker missing warning if deleting the .stfolder in syncthing folder’s root.
Hmmm… I did not setup ignores? Where do you get that from or is it misunderstanding because of “Ignore permissions” is set on both nodes? Just for info: I’ve set up ignore permissions initially because it’s the first time I try to sync data which all belongs to the “root” owner from ext4 (device A) to zfs (device B). I’m not using restrictions, so Syncthing is running as root and the zfs root is also owned by root. Not expecting trouble here.
curl -X GET -H "X-API-Key: XXX" "http://localhost:20080/rest/db/file?folder=wm9iy-ye9fd&file=lanprov/Spiele/RedAlert1/Maps/Snapshot"
No such object in the index
Tried to add front and trailing slashes, still no object found in the index.
I guess I can build stindex with the build procedure already known from st-android? The only difference would be to build all packages and not just target ‘syncthing’, right? Sure, will try that. Do you require stindex idxck from both nodes or just B (who from my point of view has missing sth in index)?
Yeah the procedure is the same, just a different package. It will be more interesting for the device where the entry is missing, but it might be useful to run against both.
It is very strange how it got damaged. Checked kernel logs of A, the USB device seems okay and did not disconnect unexpectedly while scan/sync. Renamed the index folder while st was off and went again to a fresh start. Let it be over night, checked in the morning and all states show the same on A+B and all files seem to be there. Now running a comparison of file contents with total commander between both datasets of A+B.
Could it be some racyness because of unsuccessful connection attempts? I noticed during the second run in the logs that device C was permanently trying to connect to A. C was there before I got the new OS installation on A because A had another syncthing device id running in the past. A correctly rejected every connection attempt of C . I have stopped C’s syncthing instance short after starting my second try after index reset.