Newly added folders always out of sync "item changed locally."

New user trying out syncthing but having problems.

Setup:

client a

OS: ubuntu 25.04

syncthing v2.0.0 “Hafnium Hornet” (go1.24.6 linux-amd64) debian@github.syncthing.net 2025-08-11 20:16:10 UTC [noupgrade, noupgrade]

filesystem: ext4

Client b

ubuntu 24.04

syncthing v2.0.0 “Hafnium Hornet” (go1.23.9 linux-amd64) root@buildkitsandbox 2025-08-13 11:49:55 UTC [modernc-sqlite, noupgrade]

filesystem: ext4.

Problem

Client a has a send only folder and client b has a receive only folder.

Whenever a folder is added to client a, syncthing on client b reports the folder as changed locally - “Local Additions The following items were changed locally.” The only happens for folders and for every folder added after the initial sync.

There is no antivirus or other scanning software on client b. The filedates are similar although there is a timezone difference. Here is the REST data from client a and client b:

client a: curl -s -H X-API-KEY:xxx “link/rest/db/file?folder=folder1” --url-query “file=3”

{
  "availability": null,
  "global": {
    "blocksHash": null,
    "deleted": false,
    "ignored": false,
    "inodeChange": "2025-08-22T14:08:00.609991368-04:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2025-08-22T14:08:00.609991368-04:00",
    "modifiedBy": "cleinta",
    "mustRescan": false,
    "name": "3",
    "noPermissions": false,
    "numBlocks": 0,
    "permissions": "0775",
    "platform": {
      "Unix": null,
      "Windows": null,
      "Linux": {
        "Xattrs": []
      },
      "Darwin": null,
      "FreeBSD": null,
      "NetBSD": null
    },
    "sequence": 550828,
    "size": 128,
    "type": "FILE_INFO_TYPE_DIRECTORY",
    "version": [
      "cleinta:1755886095"
    ]
  },
  "local": {
    "blocksHash": null,
    "deleted": false,
    "ignored": false,
    "inodeChange": "2025-08-22T14:08:00.609991368-04:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2025-08-22T14:08:00.609991368-04:00",
    "modifiedBy": "cleinta",
    "mustRescan": false,
    "name": "3",
    "noPermissions": false,
    "numBlocks": 0,
    "permissions": "0775",
    "platform": {
      "Unix": null,
      "Windows": null,
      "Linux": {
        "Xattrs": []
      },
      "Darwin": null,
      "FreeBSD": null,
      "NetBSD": null
    },
    "sequence": 550828,
    "size": 128,
    "type": "FILE_INFO_TYPE_DIRECTORY",
    "version": [
      "cleinta:1755886095"
    ]
  }
}

client b: curl -s -H X-API-KEY:yyy “link/rest/db/file?folder=folder1” --url-query “file=3”

{
  "availability": [
    {
      "id": "cleinta",
      "fromTemporary": false
    }
  ],
  "global": {
    "blocksHash": null,
    "deleted": false,
    "ignored": false,
    "inodeChange": "1969-12-31T19:00:00-05:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2025-08-22T14:08:00.609991368-04:00",
    "modifiedBy": "cleinta",
    "mustRescan": false,
    "name": "3",
    "noPermissions": false,
    "numBlocks": 0,
    "permissions": "0775",
    "platform": {
      "Unix": null,
      "Windows": null,
      "Linux": {
        "Xattrs": []
      },
      "Darwin": null,
      "FreeBSD": null,
      "NetBSD": null
    },
    "sequence": 550828,
    "size": 128,
    "type": "FILE_INFO_TYPE_DIRECTORY",
    "version": [
      "cleinta:1755886095"
    ]
  },
  "local": {
    "blocksHash": null,
    "deleted": false,
    "ignored": false,
    "inodeChange": "2025-08-22T14:08:10.167033503-04:00",
    "invalid": true,
    "localFlags": 8,
    "modified": "2025-08-22T14:08:10.167033503-04:00",
    "modifiedBy": "cleintb",
    "mustRescan": false,
    "name": "3",
    "noPermissions": false,
    "numBlocks": 0,
    "permissions": "0775",
    "platform": {
      "Unix": null,
      "Windows": null,
      "Linux": {
        "Xattrs": []
      },
      "Darwin": null,
      "FreeBSD": null,
      "NetBSD": null
    },
    "sequence": 532228,
    "size": 128,
    "type": "FILE_INFO_TYPE_DIRECTORY",
    "version": [
      "cleintb:1755886092",
      "cleinta:1755886095"
    ]
  }
}

here are file stats:

client a:

Access: 2025-08-22 14:08:00.615938237 -0400
Modify: 2025-08-22 14:08:00.609991368 -0400
Change: 2025-08-22 14:08:00.609991368 -0400
Birth: 2025-08-22 14:07:55.191938270 -0400

client b:

Access: 2025-08-22 18:08:12.675033493 +0000
Modify: 2025-08-22 18:08:10.167033503 +0000
Change: 2025-08-22 18:08:10.167033503 +0000
Birth: 2025-08-22 18:08:10.162033503 +0000

Questions

  1. How exactly does syncthing determine that the file has been locally changed? Is the above data sufficient to troubleshoot the problem?
  2. Is the timezone difference causing the issue?
  3. Initial AI analysis suggested that it is an inode problem inside the syncthing database and that the database might be corrupt. I doubt this.Rescanning as suggested does not fix the problem.
  4. If I remove the folder and reshare it, the issue is solved for this folder however any folders added after the initial scan show up on client b as changed locally.
  5. Is this a known issue?
  6. How to fix this problem? Clicking revert local changes clears the error for this folder but I can’t determine any actual change it made and all new folders still have the problem.

Just adding a screenshot to easily see and compare the differences between the two.

Can you also add screenshots from the Web GUI? Specifically, please unfold the folder information on both sides and include them in the images.

Thanks that is a pretty helpful screenshot.

I upgraded to the latest version on both clients: syncthing v2.0.3 “Hafnium Hornet” (go1.25.0 linux-amd64) debian@github.syncthing.net 2025-08-22 07:00:05 UTC [noupgrade]

Something else interesting I just noticed, Pressing the Rescan button the client b where the error is displayed (receive only) does not resolve it however rescanning on client a (send only) resolved the error on client b!

I am not sure what this indicate how I would like to get it resolved so I can setup file versioning and have more confidence on the syncing.

I retract my previous statement, clicking rescan on the sending client does not always resolve the conflict on the receiving client.