Elemente lassen sich nicht synchronisieren

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.)

1 Like

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)

2 Likes

I am quite sure that yes (toilet, mobile and lazy).

Edit: Now in front of a pc, I can confirm that.

2 Likes

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.