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. 
This is a screenshot of the folder on the receiving side, I’ve enabled all the logs but from a quick overview they appear to be full of private informations, there is a way to generate a log without private infos?
File names are generally needed to make sense of the problem. So, not really.
Rsync with 8M files, 6TB, and bad (extremely high latency) connections - good luck with that.
That why I’m trying this software. not so much other applications can build and replicate difference as a data content, avoiding corruption during transfer. It just awesome.
1 Like
Hi:
I’m sorry if this has already been discussed - I can’t imagine it wouldn’t have been - but isn’t there a use case for having an automatic override option on a Receive-Only folder? (With appropriate warnings, etc)
I get where Audrius is coming from - but the benefits of the peer-to-peer, automagically-resuming wonders of Syncthing give it applications beyond just ‘bi-directional syncing’, where rsync wouldn’t be able to cope.
Oh it’s been discussed, to death.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.