Hello, I’m running Syncthing from a Docker container by linuxserver on my Pi4. I’ve created on my desktop computer with send only settings and a receive only folder on the Raspberry. After the complete syncronization of the folders on the raspberry I have a lot of Locally changed items appearing. If I press on the red button nothing happens and in the logs I have this error: “Revert: directory is not empty; files within are probably ignored on connected devices only” It’s strange because I haven’t added or modified anything, out of ideas I’ve tried deleting everything on the receive side and after the complete sync happens the same. The issue appears only on folders and not on single files. Any ideas?
Do those folders exist on other devices? It seems that something is creating them on the pi, and they are not empty as well.
It’s a sync only between a device wih a send only folder and the Pi with the receive only. They should be a mirror, I don’t understand why the folders are seen as local change while they are the same on both drives. Forgot to say that on the Pi the fs is btrfs and on windows ntfs
I suggest you compare the two in details. It could be that you need to select ignore permissions on linux if you are syncing from windows (or on both sides ideally).
Thank you, I will try it, but is strange that on the same system I have a different shared folder with the same settings, so without ignore permissions, and it works fine
Hello, I’ve set ignore permissions on both the send and receive folder on the two systems, same error persisted so I’ve tried deleting the files on the receiving end. After the resyncing the folder deleted has the same permissions as before and appears changed compared to the send side. In the send side the permissions are rwxrwxrwx and on the receiving side are rwxr-srwx. I’ve tried setting up the same permissions manually but the error of these files out of sync persists… Something else to try?
Changing the permissions after the fact won’t help, as the file already counts as modified. Perhaps you should start from scratch, with permissions ignored on both sides from the beginning, as it seems something is modifying permissions.
Deleting the folder and wait for it to resync is not enough? You suggest deleting the shared folder in syncthing and delete all the local files and recreate it on the receiving side?
No, just remove the folder from syncthing, and when adding it back check ignore permissions on both sides.
I’ve removed and readded the shared folder but after the scan is completed with the ignore permissions flag the same folders are marked as changed locally and display the same error as the first post
I suggest you post some screenshots and logs.
Regarding logs the only interesting thing is the error posted on the first post. You suggest enabling some particular debugging facilities for this issue?
I’d like to see as much as possible.
Same story, I assume send only -> received only assuming master -> slave, as the most sync tools do. Regardless of slave state (changed\deleted) it always has to be a mirror of the master by override data. That concept, I assume not working in this situation.
So i see accumulation of errors , and really has no idea how to resolve it, Guess, it something in a implementation of principle send only -> received only …
You might be misunderstanding what send only/receive only means.
Receive only does not mean “I will follow others unconditionally”, it means “I won’t send my local changes to others, but keep them local”, which is what leads to this state, when receive only end has local modifications.
I did understood how it processing by such settings.
I’m wonder if it possible to add a blind data transfer to a remote node. Like in my scenario: Single Master -> many Slaves … ?
That would be great, and eliminate construct like send only -> received only, that cause an error, due to people trying to reproduce it by options that probably close to, but not exact.
You should just use a different tool. You can probably run rsync on a cron for that.
Syncthings main purpose is bidirectional sync, sure receive only send only folders act as a convenience in some scenarios, but master to many no-questions-asked slaves is not a model we support, nor do we want to support.
Well I certainly support one-to-many distribution as a valid use case, but in contrast to rsync this is done in a “cooperative” fashion in Syncthing. Files are “pulled”, not pushed, and enforcing a lack of changes on the receiving side requires discipline there. (And/or use of the revert plus override actions interactively.) If the receiving side can be disciplined appropriately this can work very well.
My comment is in relation to no-questions-asked i-will-tramp-any-local-changes, which is what is expected here.
Right, which is well established that we won’t do. But if the need for trampling is avoided it’s fine. 