I have a central server which pushes changes to 100+ other hosts, all of which are configured read-only. The central server writes to a file called
_timestamp once a minute, and is checked on all the remote hosts. On one host this file has stopped updating. When I query
/rest/db/file, it says:
NJKFFJO is the host in question, and
HGDSIPZ is the central host.
Now this is incorrect, as NJKFFJO definitely did not modify the file. However even that issue aside, I can’t get syncthing to correct the issue. When I
POST /rest/db/revert?folder=myfolder, I get a 200, but nothing happens, and the file is still “stuck”. I tried
POST /rest/db/scan as well, also no joy.
Logs say nothing other than:
Jun 01 18:21:56 myhost syncthing: [NJKFF] INFO: Reverting folder myfolder
Jun 01 18:38:57 myhost syncthing: [NJKFF] INFO: Reverting folder myfolder
Unclear. Full screenshot of the UI might tell us more.
Just to close this out, I addressed the issue by just resetting with
I can attest to this being a recent issue. I too have a folder that i am SENDING to, ie. receive only on the other end, and the receiving end keeps saying “revert local changes”, even though NO local changes were done.
I even deleted the folder and i re-shared it on the receiving side, re-syncd and same issue is occuring… That dreaded message REVERT LOCAL CHANGES showing for literally ALL files that were just sync’d.
This is definitely a bug because it never happened before. although im not sure which syncthing version has broken this as i only now recently viewed my server GUI after a long time.
Currently on version 1.23.5 on both systems.
So after many hours of trying to figure out what is wrong.
And since i also tried resetting the DB as OP suggested for the receiving folder as well as the sending folder (believe it or not that didnt work either).
Let me clarify that the receiving folder is sitting on a veracrypt volume (and always was with no issues until recently)
Creating new test folders on the veracrypt volume, syncs through just like my original folder, but gives the same issue as originally posted.
Creating new test folders on a non-veracrypt volume syncs and doesnt give that issue, everything stays green!
So i decided to tick the box in the receiving folder “Ignore Permissions”, after that, i pressed Revert Local Changes once and then everything STAYED green.
Can you tell me why this happened and if i have done the correct thing by checking the “Ignore Permissions” box?
I dunno, not enough information given. If setting ignore-permissions helps then I guess the veracrypt volume doesn’t preserve permissions properly.
I can tell you that syncing send-receive between the veracrypt volume and another server has no issues, but only when the veracrypt volume is set on receive-only will cause 2 issues. 1. it will bring up that “Revert local changes” and 2. it wont delete files, but will only delete folders.
I dont think my veracrypt volume has any issues though.
In your opinion is it safe to keep setting this ignore-permission to true?
I really dont want to “preserve” any permissions between file systems, whatever gets created on the remote system i want it to recreate the file with its current permissions (not that theres any difference in permissions between systems) but this setting seems to solve my problems.
Also i found this: Ignore Permissions as default on all folders however not sure if this issue in the issue tracker was completed?
Doesnt it seem like users would be better off if the “Ignore Permissions” was by default set to true? Im not sure how much copying permissions would apply to the majority of users.
What filesystem are the files and directories originating from, and what filesystem is being used inside the VeraCrypt container?
from an Ubuntu home dir to a remote Veracrypt NTFS partition.
Even manually I am unable to change the permissions of any files or dirs on the veracrypt partition, as im not sure why, all my veracrypt volumes are like this anyway. Any idea why this is?
NTFS doesn’t keep unix permissions, so setting ignore-permissions is proper.
thank you for clarifying!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.