By the way, for security reason, this shouldn’t be able to be set on the receiver because the user could change it and still mess up; it should be set from the master sender. 
I understand, trying to be politically correct, your competitor has an option to share READ-ONLY secret which used at the receiver, user cannot do anything with. I used this software before Syncthing and liked it (feature, not software lol)
1 Like
Audrius, Jakob,
The architecture I need is a send/receive workgroup that also syncs to a computer that only aggregates files and can never send any changes back to the work group. This seems obvious to implement with a “receive only” designation on the aggregating computer.
However, what I hear you saying is to set all the file permissions on each work computer to protect them. However, when Audrius says, “mark the files read so users won’t mess with them,” that is ignoring the fact that all the work computers should mess with each others’ files (keeping them updated and sync’d), so I can’t file permission protect them against each other!
Only the aggregating computer should not mess with others, so only it must be designated as “receive only”. I can’t set file permissions on each of the work computers to refuse writing from only the aggregating computer. Besides, conceptually a program like Syncthing should sync files and permissions that are present, not levy a changed set of what those requirements are.
The debate about how to ~implement~ “receive only” behavior is a different beast. I hear Jakob’s explanation that this really must be implemented by all the work computers refusing updates from the aggregating computer. If that is the best way to implement the solution, then so be it. I’m okay configuring each work computer to refuse updates from a named aggregator computer.
This is where you set it up so that a syncthing user owns the files and no one else messes with them. It is now receive only by way of no changes happening there. Set the rescan interval to zero if you like.
Jakob,
I appreciate your metered responses in the forum. Your challenge to carefully define the use case and corner cases is heard. I could make an attempt at this - maybe a list of of different situations or actions and what the desired behavior would be. If you or someone more familiar with the program could lay out the challenging use cases, I would be happy to populate the list with my vision of what a receive only node would do.
Regarding file permissions, you again evoke a good clarification about what I said. Essentially this: I’m not worried about others messing with the files. The threat is ME, and user errors, and that’s why file permissions aren’t the right answer. For example, if I am doing activities on the aggregating computer and I accidentally delete/change something, I do not want this going back to the work computers. If you are speaking about creating a new user that alone has certain file permissions, that is changing the data I am trying to sync at which point syncthing is not a passive tool but an invasive requirements driver.
I would rather want the ability to once config the aggregator node as a “receive only” - in other words, if it deviates from any other peer in a sync group, it will not offer any mods, ads, or deletes to any other computer. It will continually assume itself is in error and take changes from other peers to match the peers.
And all of this can be enforced by permissions and a different user, so you are no longer a threat and you can no longer modify the files, I still don’t understand how this is different from syncthing just bulldozing your changes and getting your files into literally the same state they would be if you didn’t have any permissions.
Yeah, perhaps it’s nice not to have to add users and tweak permissions, but where is the real value add/incentive for someone to spend weeks writing and testing a feature that can simply achieved by features provided by the OS?
We are going in circles in both threads, you repeat the same thing that permissions are not a solution as you are the threat, yet don’t quantify how you are the threat if you have no write access to the files.
It seems we are going in circles, as you repeat the same thing against a growing chorus identifying a missing feature (receive-only). I get it that you and others are doing Syncthing for free and you can add whatever features you want or don’t want. However, to simply keep saying the same thing over and over and telling people what they want is wrong seems to be unproductive.
So… I decided to write up a short table of desired behavior in all conditions and corner conditions Jakob spoke about. If nothing else, it is a consolidation of what the request is. Maybe consider the short table, instead of telling others that their idea is pointless, and demanding them to defend why they would want such a crazy thing. Maybe just hear it for a minute and ponder why it’s so offensive to you that people want something that they thing would be valuable to their computer life.
I am not saying it’s useless, I just can’t for the life of me understand how permissions are not solving this. It seems permissions are solving the exact same problem of reverting any local changes by effectively not allowing you to make any changes. Can you explain what part of this problem permissions do not solve? As in what actual actions do I need to perform to end up with two different end states in the receive only case and the using permissions case? Or what is having permissions not allowing you to do?
Edit: I have now read that you want to revert local changes later, which I guess is not possible under permissions. This could be done with send only and send and receive yet only between two devices, hence I guess this has merit. Most if not all previous receive only cases wanted local changes to be reverted immediately which is essentially just a substitute for permissons.
2 Likes
For an Android ‘receive only’ device (say, a copy of another device’s photos) you don’t really have the disk permissions option. The user may simply want to delete some of the photos for space reasons, without a) those deletions to propagate back, and b) the deleted files re-downloaded right away. On the other hand he may want new photos downloaded. I guess the above should be considered one particular use case. Among others.
This is already possible in advanced options marking ignoreDeletes, which simply refuses any deletions from others.
Not really, because you may still want to fully sync files (including deletions) among peers, but then there’s that Android device which shouldn’t propagate deletes.
For newcomers to the thread, check out both threads for full understanding:
Also, here is a “proposal on the table” of how to implement the proposal. If users coalesce around this description, it would be easier for developers to make the change.
I haven’t read the entire 2 threads, so maybe this idea has already come up.
In my opinion it makes more sense to set restrictions on the pulling side. I mean, who guarantees that the other peer is actually configured “receive-only” when I don’t want to pull changes from that device? It feels more intuitive to say on my own device that I don’t want something instead of relying on the other side not to send something.
Following this approach, a “receive-only” setup could be achieved by making the already existing “send-only” mode device specific. This would allow to “protect” from pulling changes from some peers while still being able to sync both ways with the rest.
Not sure about Syncthing’s internals, but maybe this approach would also be easier to implement? I mean, “send-only” is already implemented. Only the device specific configuration is missing.
1 Like
The problem is protecting from another device is an illusion. Consider the case of three devices, where A only accepts changes from B but not from C. If B doesn’t have anything specific set up, it will get changes from C and thus A will pull these changes from B, so in the end it still got the changes from C.
Yes, in this scenario B would “approve” the changes from C. So with my approach you still need to rely on other devices to be configured in a particular way.
However, those devices are on the side being protected.
The use case for me would be that A and B are my own nodes and C is a friend’s device. I can easily configure my own two devs to be “send-only” regarding C. However, as I have no access to my friend’s device I can not ensure it is actually configured “receive-only”. So for me it makes still sense to have the shields were I want the protection, even if it requires to setup those shields manually on multiple devs.
Just out of interest: Would my approach even be possible to implement without disproportionate effort?
Martchus, I see a big administrative problem with your suggested pull-protection mode. If you already have a large cluster of synched nodes and you want to install a receive-only node into that mix, to handle it your suggested way would force you to go to all your other nodes and re-configure them. Which may be difficult - right now, for example, one of my “nodes” is an Android tablet with my father in a remote location. But it is difficult enough even when nodes are technically accessible.
Of course this is also true:
[Martchus] The use case for me would be that A and B are my own nodes and C is a friend’s device. I can easily configure my own two devs to be “send-only” regarding C. However, as I have no access to my friend’s device I can not ensure it is actually configured “receive-only”.
But, this is already the case today, and will always be, with or without receive-only: With a cluster of synch’ed nodes you can’t protect against “unwanted” deletes or edits on one of them if you also want to actually keep them in synch. Can’t have it both ways, in that setup. This still doesn’t preclude a use case for a (locally configured) receive-only node.
1 Like
Three devices:
- A) Send and receive
- B) Receive only
- C) Receive only
Folder sync: A—>B—>C
Currently it looks like C is getting synced in my setup, surely this shouldn’t be the case, right?
It does forward changes received from others, it just ignores local changes to the local filesystem.
Gotcha, thanks!