One of the file is KTO_DAT.VMB and on my Synology I use the port 7070 instead of 8384, so I use
https://192.168.168.111:7070/rest/db/file?folder=ccbah-xmdl5&file=/volume1/Buchhaltung/Buchhalter/FORMULAR/KTO_DAT.VMB
Result:
CSRF Error
One of the file is KTO_DAT.VMB and on my Synology I use the port 7070 instead of 8384, so I use
https://192.168.168.111:7070/rest/db/file?folder=ccbah-xmdl5&file=/volume1/Buchhaltung/Buchhalter/FORMULAR/KTO_DAT.VMB
Result:
CSRF Error
I am not sure anymore whether CSRF is due to the API key or https. If you use https, then that bit of the docs is relevant:
(add
-k
flag when using HTTPS with a Syncthing generated or self signed certificate)
Otherwise double check your api key (the abc123 part in -H "X-API-Key: abc123"
).
I deactivate https:// in the GUI section and run
http://192.168.168.111:7070/rest/db/file?folder=ccbah-xmdl5&file=/volume1/Buchhaltung/Buchhalter/FORMULAR/KTO_DAT.VMB
in a new brwoser instance. I must give my user and password and got the same result:
CSRF Error
How to use in a link?
Don’t know whether/how it would work in a browser. Use curl
as explained here: https://docs.syncthing.net/dev/rest.html#api-key
I will try or maybe you have a cmd command
In this way I´m not expert enough, I need a full link I can use.
Hello:
Try this:
curl -k -X GET -H "X-API-Key: abc123" 'http://192.168.168.111:7070/rest/db/file?folder=ccbah-xmdl5&file=Buchhalter/FORMULAR/KTO_DAT.VMB'
You’ll need to insert your actual API Key to replace the abc123
in there - you can read this out of the Actions > Settings window in the Syncthing GUI.
(The path/to/an/out-of-sync/file
needs to be relative to the Shared Folder - not from the root of the volume.)
If I use that in CMD I got
root@Synology:~# curl -k -X GET -H "X-API-Key: abc123" 'http://192.168.168.111:7070/rest/db/file?folder=ccbah-xmdl5&file=Buchhalter/FORMULAR/KTO_DAT.VMB'
Not Authorized
root@Synology:~#
As I pointed out:
(Assuming you didn’t redact the command before posting it here)
Done:
root@Synology:~# curl -k -X GET -H "X-API-Key: xxxxxxxxxxxxxxxxxxxxxxxxx" 'http://192.168.168.111:7070/rest/db/file?folder=ccbah-xmdl5&file=Buchhalter/FORMULAR/KTO_DAT.VMB'
No such object in the index
root@Synology:~#
So I think the file is not indexed, but why was in the past indexed?
What happens if you run that same command on the other machine?
(Obviously you’ll need to change the IP address and API Key for that)
I´m surprised, the same:
root@Synology:~# curl -k -X GET -H "X-API-Key: yyyyyyyyyyyyyyyyyy" 'http://192.168.158.113:7070/rest/db/file?folder=ccbah-xmdl5&file=Buchhalter/FORMULAR/KTO_DAT.VMB'
No such object in the index
root@Synology:~#
But the peer (folder) shows “Up to Date” (?)
The file is available on both sides.
Ah - I see.
ccbah-xmdl5
is the ‘Music’ folder.
For the Buchhaltung folder, this ID needs to be 6mnwv-lrpjc
(according to your screen shots here).
Try again on both systems with this correct folder ID and post the results.
Understood. Both sides:
Synology 1815:
root@Synology:~# curl -k -X GET -H "X-API-Key: xxxxxxxxxxxxxx" 'http://192.168.168.111:7070/rest/db/file?folder=6mnwv-lrpjc&file=Buchhalter/FORMULAR/KTO_DAT.VMB'
{
"availability": null,
"global": {
"deleted": false,
"ignored": false,
"invalid": false,
"localFlags": 0,
"modified": "2006-08-21T17:26:40+02:00",
"modifiedBy": "FSBSS4H",
"mustRescan": false,
"name": "Buchhalter/FORMULAR/KTO_DAT.VMB",
"noPermissions": true,
"numBlocks": 1,
"sequence": 15499,
"size": 21120,
"type": "FILE",
"version": [
"FSBSS4H:1",
"MLCCOCU:1"
]
},
"local": {
"deleted": false,
"ignored": false,
"invalid": false,
"localFlags": 0,
"modified": "2006-08-21T17:26:40+02:00",
"modifiedBy": "FSBSS4H",
"mustRescan": false,
"name": "Buchhalter/FORMULAR/KTO_DAT.VMB",
"noPermissions": true,
"numBlocks": 1,
"sequence": 15499,
"size": 21120,
"type": "FILE",
"version": [
"FSBSS4H:1",
"MLCCOCU:1"
]
}
}
root@Synology:~#
Synology 412
root@Synology:~# curl -k -X GET -H "X-API-Key: 2oa2SRTFsJA6zaSJJSaeFv4YgvwYfoYA" 'http://192.168.158.113:7070/rest/db/file?folder=6mnwv-lrpjc&file=Buchhalter/FORMULAR/KTO_DAT.VMB'
{
"availability": [
{
"id": "yyyyyyyyyyyyyyyyyyyyyyy",
"fromTemporary": false
}
],
"global": {
"deleted": false,
"ignored": false,
"invalid": false,
"localFlags": 0,
"modified": "2006-08-21T17:26:40+02:00",
"modifiedBy": "FSBSS4H",
"mustRescan": false,
"name": "Buchhalter/FORMULAR/KTO_DAT.VMB",
"noPermissions": true,
"numBlocks": 1,
"sequence": 15499,
"size": 21120,
"type": "FILE",
"version": [
"FSBSS4H:1",
"MLCCOCU:1"
]
},
"local": {
"deleted": false,
"ignored": false,
"invalid": false,
"localFlags": 0,
"modified": "2006-08-21T17:26:40+02:00",
"modifiedBy": "FSBSS4H",
"mustRescan": false,
"name": "Buchhalter/FORMULAR/KTO_DAT.VMB",
"noPermissions": true,
"numBlocks": 1,
"sequence": 15458,
"size": 21120,
"type": "FILE",
"version": [
"FSBSS4H:1",
"MLCCOCU:1"
]
}
}
root@Synology:~#
This is super weird. That looks like the issue fixed in 1.4.0: missing index on 412 thus the other one believes it has nothing. but that should be fixed for you and even if it isn’t, stindex should pick it up. and there’s nothing here that would explain the missing needs found by stindex.i am lost.
Are needs written in the same checkpoint? (Dinner, mobile, and lazy)
I am quite sure that yes (toilet, mobile and lazy).
Edit: Now in front of a pc, I can confirm that.
To fix this, ./syncthing -reset-deltas
has to be used again, or is this automatically fixed in rc.11? Or how I can clean up the database to be safe?
After finishing of scanning all the peers on both servers, the result is good and both servers are running without deviations. Also a additional activation of a Synology with ST v1.3.4 work without problems.
In the next days we will see, how all work now.