Filed this as a bug here: Files show as locally modified when logs says they are unchanged · Issue #10545 · syncthing/syncthing · GitHub
Honestly, I don’t think filing the bug will help much, as the same people are active both here, and on GitHub. As suggested there, please first upgrade to the newest release from the v2 branch. You will probably need to switch your repository to https://apt.syncthing.net, as Debian/Ubuntu is known to stuck to the old versions of Syncthing that are no longer maintained.
If the problem persists even on the new version, then please post screenshots, logs, and the same API output as previously.
I started here to get support, in case it was user error. But from the various responses above, it looks like it is a bug, so normally the proper place to put that is in the issue tracker.
Someone in the thread above said that the version number shouldn’t matter, so I haven’t tried upgrading it on Ubuntu before filing, but it will be my next thing to try.
Yeah, but if forum troubleshooting hasn’t led to anything concrete yet, it doesn’t really make any difference if you open an issue on GitHub, as currently, the bug report will just hang there with no further action possible until we manage to find the culprit or perhaps reproduce the problem with generic instructions.
Whether anything happens or not, it seems to be a bug so the right place for it is the issue tracker. I’ve done everything I can to try and provide the information asked and the help has dried up so this is the logical conclusion.
And the issue was closed with a patronizing response. So nobody here has an idea of what the problem is and the developers aren’t interested in working with me to find out. Not a great look for the project.
You have both sides on v2. Did you upgrade the older Ubuntu setup or was it a full reinstall with a fresh database?
I’d like to rule out that there are still remnants of same database quirks that were simply migrated.
The permissions between the files are different. The file globally is advertised with permissions 0644, but once synced locally, ended up with 0755.
As I have already suggested on the github issue, the problem is with your filesystem not retaining permissions properly, as exFAT does not support the full permission set.
This is not much todo with syncthing, but more todo with the filesystem of choice.
You can enable “ignore permissions”, this is why the option is there.
1 Like
But that doesn’t explain the block hash mismatch?
Fair, that’s another difference.
I’d md5sum the files on both sides and see if they are the same.
BlocksHash is just a hash of hashes, so if you’re capable, you could open up the sqlite db and if the hashes of the two blocks match.
It’s hard to guess what it could be given the very limited set of features that exFAT actually supports.
@Kylotan could you check if the sha256 hash on both sides really match? I’d like to gather some “ground truth” to rule out any OS funzies.
Powershell:
Get-FileHash <your file path>
Bash:
sha256sum <your file path>
I upgraded the Ubuntu setup as requested on the issue, before it was closed. I wouldn’t know how to remove the database, and that wasn’t suggested to me.
As I have already suggested on the github issue, the problem is with your filesystem not retaining permissions properly, as exFAT does not support the full permission set.
[…]
You can enable “ignore permissions”
And as I have already said above ( Files are locally modified when logs says they are unchanged - #3 by Kylotan ) , I set “Ignore Permissions” to Yes long ago and it makes no difference, despite rescans.
I posted API results from both sides for a sample file affected by this and they both seem to be returning “noPermissions: false” which, if it relates to the same setting, implies it might be ignoring what I select in the UI.
Is the “Ignore Permissions” option enabled in the Advanced tab when you edit the affected folder? I’m asking because there are also settings for “Default Folder” if you go to Actions → Settings, but those are only applied when you create new folders, and not to already existing folders.
Sure.
Windows 11 reading the local file in the Send folder:
> Get-FileHash IMG_0706.jpg
Algorithm Hash Path
--------- ---- ----
SHA256 C64B2502221D5EE900949541C9204080CFCA0578AEA526BF57C35784C5D7BCC1 D:\photos\2006\Aug 2006\IMG_0706.jpg
Windows 11 reading the remote file in the Receive folder via a mapped drive:
> Get-FileHash "\\HOMEHUB\backups\Static\photos\2006\Aug 2006\IMG_0706.jpg"
Algorithm Hash Path
--------- ---- ----
SHA256 C64B2502221D5EE900949541C9204080CFCA0578AEA526BF57C35784C5D7BCC1 \\HOMEHUB\backups\Static\photos\2006\Aug 2006\IMG_0706.jpg
Ubuntu reading that file locally from the Receive folder:
$ sha256sum IMG_0706.jpg
c64b2502221d5ee900949541c9204080cfca0578aea526bf57c35784c5d7bcc1 IMG_0706.jpg
1 Like
Thanks for going the extra mile. That looks indeed very suspicious.
The next step would be a reset of Syncthings internal database.
The REST API allows to do this per folder: POST /rest/system/reset — Syncthing documentation
For how long have you been using Syncthing? There was a change in blocks hash calculations (actually the used block size) a few years back. Under v1, things should clear up automatically if the difference shows up and both sides do support the new block size. But I’m not sure if that code path has been tested with v2, so might behave differently.
I have seen this happen each time I reinitialized my Syncthing database on a receive-only folder too. It seemed to me like an harmless bug that was easily worked around by asking to force conflict resolution on the receive-only side when it didn’t eventually fix itself.
That said in my current situation (see my topic on Support about huge folders and v2) Syncthing reports :
- nearly 17 million out of sync items for a 29+ million folder,
- about as many locally changed items (a bit lower : 16719656 instead of 16885950 currently to be precise).
The folder is untouched from a state in December 2025 when I started the migration, almost all files should be completely identical. In fact I know for sure that the files data and mtime are identical for the first one listed in “out of sync items” that wasn’t created since December. The only change according to stat vs the send-only side is the access time (which could explain the symptoms if Syncthing attempts to sync the atime value : noatime was activated at different times on the source and destination sides, recent files probably have the same atime but not older files).
Handling that many differences can’t be free which is why I paid a bit more attention this time given my current woes.
The number of Out of Sync and locally changed Items seems to go down slowly while the folder is in Preparing to Sync state.
Zabbix monitors the value of “needFiles” from Syncthing API which isn’t the same as these two apparently but is in the same ballpark, currently :
- Out of Sync : 16 692 125,
- Locally Changed : 16 522 253,
- needFiles in JSON from API : 16 037 923.
Based on the last 24h it will probably take approximately 6 months for these values to reach 0.
I’ll post this in the topic I started about my current attempt at migrating to v2 too.