Remote Device always shows "Syncing"

Support
21

Great many thanks, Simon! Sadly this Trust Level did not help much - I shall wait 5 hours now :sweat_smile:

I just have one backup for my SSD data, which can get up to 8 TB large.

And instead of backing this up in the same room, so that the backup get’s lost in a fire, I moved the disk to a remote location.

Nothing special about this :wink: And I only need one backup - the data changes very rarely and soon never again!

Locally, I would use “rsync” to update the backup - and wanted to use Syncthing to do the same remotely.

Really nothing special.

But therefor, the remote side only shall be updated manually and after I made sure things are OK - which I can do with my local “find” and “cksum” outputs!

When I see that everything is fine and only the new stuff is missing, I rescan locally and this delta should be synced to the remote location.

Maybe that made it more clear?

It’s just a remote backup, really - and handled liked a local backup.

I will not try to revert anything but re-add both devices and folders, starting anew.

In the current state I cannot be sure that nothing get’s deleted remotely - and it is no easy task to drive there again to copy the SSD back to the hard disk again. AND, there would be NO backup for some time, which I cannot risk.

Thanks again, I will report how it did go!

22

I removed the remote device and added it again.

It updated the last changes and then finished syncing.

The displayed state is still strange, as “Syncing (4%, 3.43 TiB)” will be shown and as it seems ALL pre-existing items will be listed as “Out of Sync Items”:

Screenshot 2025-01-08 at 10.32.25

I cannot find a way that pre-existing items will be shown in a synced way - which makes it difficult to trust the situation.

So, simple removing and adding the remote device did not solve the situation.

Do you think that totally removing the Syncthing configuration and repeating everything should change this?

For now, it seems that Syncthing ONLY shows items in sync then they were synced by Syncthing, NOT for pre-existing items.

I would like to SEE that things are totally in sync :wink:

23

You seem to be missing one simple fact: For you the files may look identical, but from Syncthing’s perspective (including all the metadata it considers, e.g. permissions and modification time), it does not look identical.

No amount of re-setting up the thing will change that. It will always come to the same conclusion (out of sync) from its perspective.

So either you trust that the send-only folder is the Absolute Authority. Then you can press the “Revert Local Changes” button on the receive-only side. It will make sure all metadata (and of course content itself) matches the send-only side.

Or if that sounds too dangerous for you, you’ll need to figure out what exactly are those differences that Syncthing sees. Pick any file that’s reported as out of sync and call this command on both sides:

syncthing cli debug file <FOLDER-ID> <PATH>

Where <FOLDER-ID> needs to be the ID shown in the GUI and <PATH> is relative to the folder’s root path. Then compare the output of these two and tell us where the difference is. Repeat for some more files to find a common pattern.

1 Like
24

Great advice, many thanks!

I will check this …

EDIT:

This does not seem to be possible while Syncthing is already running.

At least on Mac, there is only one “Syncthing” binary and that is the same as the daemon:

[start] 2025/01/08 11:17:41 INFO: syncthing v1.28.1 "Gold Grasshopper" (go1.23.3 darwin-arm64) builder@github.syncthing.net 2024-11-24 21:55:12 UTC [stnoupgrade]
[start] 2025/01/08 11:17:41 INFO: Using large-database tuning
[start] 2025/01/08 11:17:41 WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)
2025-01-08 11:17:41.680 Syncthing[75455:7591259] Syncthing daemon terminated (exit code 1)
2025-01-08 11:17:41.680 Syncthing[75455:7591259] Delaying daemon startup by 10.0 s
2025-01-08 11:17:52.346 Syncthing[75455:7591257] Launching Syncthing daemon
25

The syntax does not work for macOS, as it seems.

Only ever the daemon will be started …

26

It depends on which arguments you give it. syncthing cli ... never attempts to start the daemon, but connects to the running instance.

Sorry I don’t know much about macOS, but it should work just the same there.

27

Of course I used the syntax given above!

/Applications/Syncthing.app/Contents/MacOS/Syncthing cli debug file <FOLDER_ID> <RELATIVE_FILE_PATH>

And yet, it just started the daemon!

The binary sadly does not output any usage message with “–help” or “help” options

28

That seems to be the wrong binary then. I suppose it’s for the GUI wrapper. You need to find the bare syncthing binary, try this:

defaults read com.github.xor-gate.syncthing-macosx Executable
1 Like
29

Ohh, yes!

But then, the output is irritating:

syncthing: error: unexpected HTTP status returned: 403 Forbidden Debugging disabled

EDIT: I found the “Debugging” option in the webinterface, now it works!

30

Here is the modified output, I changed all string that I was not sure about putting them in public:

{
  "availability": [
    "<NUMBERS>"
  ],
  "global": {
    "blocksHash": "hQ/aqX4HRCcs9qcwj/yU7Bf+FuUpvDPdQ2NzPWdTgAU=",
    "deleted": false,
    "ignored": false,
    "inodeChange": "2024-11-17T21:46:47.02+01:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2024-11-17T21:46:47.02+01:00",
    "modifiedBy": "<MODID>",
    "mustRescan": false,
    "name": "<DIR/FILE.type>",
    "noPermissions": false,
    "numBlocks": 1529,
    "permissions": "0700",
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 11691,
    "size": 6412454025,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "<MODID>:1735838140"
    ]
  },
  "globalVersions": "{{Version:{[{<MODID> 1735838140}]}, Deleted:false, Devices:{7777777}, Invalid:{}}, {Version:{[]}, Deleted:false, Devices:{}, Invalid:{ISESWES}}}",
  "local": {
    "blocksHash": "hQ/aqX4HRCcs9qcwj/yU7Bf+FuUpvDPdQ2NzPWdTgAU=",
    "deleted": false,
    "ignored": false,
    "inodeChange": "2024-11-17T21:46:47.02+01:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2024-11-17T21:46:47.02+01:00",
    "modifiedBy": "<MODID>",
    "mustRescan": false,
    "name": "<DIR/FILE.type>",
    "noPermissions": false,
    "numBlocks": 1529,
    "permissions": "0700",
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 11691,
    "size": 6412454025,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "<MODID>:1735838140"
    ]
  },
  "mtime": {
    "err": null,
    "value": {
      "real": "0001-01-01T00:00:00Z",
      "virtual": "0001-01-01T00:00:00Z"
    }
  }
}

For me, that looks fine and does not explain why is it in the “Out of Sync” list …

31

Well you need to acquire this info on both devices and then look for differences.

32

OK, I will try to get this from the remote site.

But then … this is from the local device and it says that this file is out of sync!

And the local device shows the local and the global state - and they are equal in regards to file size, checksum, permission. modification date and so on.

As the local device still lists this below “Out of Sync”, one would assume that this is the assumption of the local device, based on what it knows about the global state!

So it IS very irritating!

33

The global state is reconstructed on each device from what it knows and what has been announced from other devices. In this case, your receive-only device does not announce its state (which is the meaning of receive-only), thus that view is not part of the global state that your send-only device can reconstruct. You need the info from the receive-only side. Not irritating, just how it works.

Oh, and you don’t need to hide the availability info. It could be very helpful when trying to determine the cause here.

34

Thanks for the explanation!

New version with availability numbers (data from the remote site only later, I cannot access it myself):

{
  "availability": [
    "7777777-777777N-7777777-777777N-7777777-777777N-7777777-77777Q4"
  ],
  "global": {
    "blocksHash": "hQ/aqX4HRCcs9qcwj/yU7Bf+FuUpvDPdQ2NzPWdTgAU=",
    "deleted": false,
    "ignored": false,
    "inodeChange": "2024-11-17T21:46:47.02+01:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2024-11-17T21:46:47.02+01:00",
    "modifiedBy": "<MODID>",
    "mustRescan": false,
    "name": "<DIR/FILE.type>",
    "noPermissions": false,
    "numBlocks": 1529,
    "permissions": "0700",
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 11691,
    "size": 6412454025,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "<MODID>:1735838140"
    ]
  },
  "globalVersions": "{{Version:{[{<MODID> 1735838140}]}, Deleted:false, Devices:{7777777}, Invalid:{}}, {Version:{[]}, Deleted:false, Devices:{}, Invalid:{ISESWES}}}",
  "local": {
    "blocksHash": "hQ/aqX4HRCcs9qcwj/yU7Bf+FuUpvDPdQ2NzPWdTgAU=",
    "deleted": false,
    "ignored": false,
    "inodeChange": "2024-11-17T21:46:47.02+01:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2024-11-17T21:46:47.02+01:00",
    "modifiedBy": "<MODID>",
    "mustRescan": false,
    "name": "<DIR/FILE.type>",
    "noPermissions": false,
    "numBlocks": 1529,
    "permissions": "0700",
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 11691,
    "size": 6412454025,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "<MODID>:1735838140"
    ]
  },
  "mtime": {
    "err": null,
    "value": {
      "real": "0001-01-01T00:00:00Z",
      "virtual": "0001-01-01T00:00:00Z"
    }
  }
}
35

I don’t get why you don’t feel like hitting the revert button, but just resetting everything seems to be perfectly acceptable risk…

Also have you set ignore permissions on both sides? I feel like a parrot for repeating that, but really it’s a no-brainer super simple change that might solve things and unless I/search missed it, you never acked doing that.

As for the debug info, as Andre said, that’s needed for the receive-encrypted side to see what’s going on. That’s because on the send-only side both the global and local version are from the send-only side and thus the same - only on the other side both versions and thus differences will be visible.

1 Like
36

Hi Simon, I simply fear that the remote data could somehow be invalidated and need to be uploaded again.

If you can guarantee that no remote or local data will be changed or rescheduled for upload, I can try the revert button - but I heavily fear some thing bad may happen, not knowing how this works and what technical steps are involved.

We now set both sites to “Ignore Permissions”!

I will add the debug output from local and remote side in the next postings, with less stuff removed!

Many thanks!

37

From the “local” site:

{
  "availability": [
    "7777777-777777N-7777777-777777N-7777777-777777N-7777777-77777Q4"
  ],
  "global": {
    "blocksHash": "hQ/aqX4HRCcs9qcwj/yU7Bf+FuUpvDPdQ2NzPWdTgAU=",
    "deleted": false,
    "ignored": false,
    "inodeChange": "2024-11-17T21:46:47.02+01:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2024-11-17T21:46:47.02+01:00",
    "modifiedBy": "JIXTTVB",
    "mustRescan": false,
    "name": "<DIR/FILE.type>",
    "noPermissions": false,
    "numBlocks": 1529,
    "permissions": "0700",
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 11691,
    "size": 6412454025,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "JIXTTVB:1735838140"
    ]
  },
  "globalVersions": "{{Version:{[{JIXTTVB 1735838140}]}, Deleted:false, Devices:{7777777}, Invalid:{}}, {Version:{[]}, Deleted:false, Devices:{}, Invalid:{ISESWES}}}",
  "local": {
    "blocksHash": "hQ/aqX4HRCcs9qcwj/yU7Bf+FuUpvDPdQ2NzPWdTgAU=",
    "deleted": false,
    "ignored": false,
    "inodeChange": "2024-11-17T21:46:47.02+01:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2024-11-17T21:46:47.02+01:00",
    "modifiedBy": "JIXTTVB",
    "mustRescan": false,
    "name": "<DIR/FILE.type>",
    "noPermissions": false,
    "numBlocks": 1529,
    "permissions": "0700",
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 11691,
    "size": 6412454025,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "JIXTTVB:1735838140"
    ]
  },
  "mtime": {
    "err": null,
    "value": {
      "real": "0001-01-01T00:00:00Z",
      "virtual": "0001-01-01T00:00:00Z"
    }
  }
}
38

From the “remote” site:

{
  "availability": [
    "JIXTTVB-DZSOUIH-V4ROJE7-AW5LME5-BM3TENN-ULEBDOJ-QPAELCZ-WVX7HAE"
  ],
  "global": {
    "blocksHash": "hQ/aqX4HRCcs9qcwj/yU7Bf+FuUpvDPdQ2NzPWdTgAU=",
    "deleted": false,
    "ignored": false,
    "inodeChange": "1970-01-01T01:00:00+01:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2024-11-17T21:46:47.02+01:00",
    "modifiedBy": "JIXTTVB",
    "mustRescan": false,
    "name": "<DIR/FILE.type>",
    "noPermissions": false,
    "numBlocks": 1529,
    "permissions": "0700",
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 11691,
    "size": 6412454025,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "JIXTTVB:1735838140"
    ]
  },
  "globalVersions": "{{Version:{[{ISESWES 1735997105} {JIXTTVB 1735838140}]}, Deleted:false, Devices:{}, Invalid:{7777777}}, {Version:{[{JIXTTVB 1735838140}]}, Deleted:false, Devices:{JIXTTVB}, Invalid:{}}}",
  "local": {
    "blocksHash": "hQ/aqX4HRCcs9qcwj/yU7Bf+FuUpvDPdQ2NzPWdTgAU=",
    "deleted": false,
    "ignored": false,
    "inodeChange": "2024-11-17T21:46:47.02+01:00",
    "invalid": true,
    "localFlags": 8,
    "modified": "2024-11-17T21:46:47.02+01:00",
    "modifiedBy": "ISESWES",
    "mustRescan": false,
    "name": "<DIR/FILE.type>",
    "noPermissions": false,
    "numBlocks": 1529,
    "permissions": "0775",
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 66361,
    "size": 6412454025,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "ISESWES:1735997105",
      "JIXTTVB:1735838140"
    ]
  },
  "mtime": {
    "err": null,
    "value": {
      "real": "0001-01-01T00:00:00Z",
      "virtual": "0001-01-01T00:00:00Z"
    }
  }
}
39

Current “local” state - it does not do anything, but shows "Syncing (6%…)

Screenshot 2025-01-09 at 15.05.39
Screenshot 2025-01-09 at 15.05.39832×674 72.9 KB

We added an Ignore Pattern for the macOS files:

._*

40

And the folder as seen on the remote site:

signal-2025-01-09-152146_002
signal-2025-01-09-152146_0021104×832 74.4 KB