You can make it as artificially complicated as you want to access the GUI, by setting it to a different address and port. That way even a quick google search will not help him to access the GUI.
@AudriusButkevicius I think the feature request that is hiding in there is just to have the option to lock the GUI or just the settings by a password which I think is not unreasonable. It is especially useful for users who use syncthing to distribute data.
You’re both right, I’m using SyncTrayzor for GUI and forgot that the Syncthing can run ‘headless’.
You can already setup a username and a password for the UI.
Sorry, I have not seen that yet.
@adi-dev That should be a easy solution for you.
Note that the SyncTrayzor UI will bypass any username or password set in the GUI, when viewed using SyncTrayzor.
Reminds me of a previous idea to implement read-only-like behavior: New Folder type: Receive Only - #33 by Martchus
@scienmind I would be fine with that being an “Advanced” setting.
I have a receive-only folder on my Android phone that shall be overwritten by other changes (on my Windows computer) automatically. I don’t want to confirm that. So I would be grateful for that option.
You mean you want it to automatically and always write over the Android data? I think if data changes independently on the Android, you’ll always be prompted by the nature of what “sync” means.
What if the file added to the Android is something you want? You really want Syncthing to delete it with no confirmation?
Yes, this is what he wants.
This is what many users want (to not get bothered by missing up-to-date data and being forced to interact with the software).
It would be very convenient if syncthing (additionally) will offer such an option.
It could be done in many ways (checkbox in folder prefs, new receive-only-w/o-prompt mode, etc.), and I’m sure and cross my fingers, the team will develop a useful/convenient solution for those, who decide to let syncthing overwrite all local changes without confirming them everytime.
Syncthing will not offer destructive options.
Sisa, if a change is made to the Android and bege just wants it automatically, continuously (immediately) and silently always destroyed, what is the purpose of making the Android change in the first place?
In the proposed use case, the user definition of “unwanted” means “any change always”. If a change on the Android is never wanted, maybe just don’t do/allow the change in the first place.
Maybe bege could jump in with a specific type of data that is appearing on the Android, in order to give more tangible context to what is going on.
That’s a good and well chosen approach.
I assume u know that the subject is not about destroying and loosing important data, it is about keeping a folder in continuous sync and (therefore deliberately) removing unwanted data from that folder.
First sentence on https://syncthing.net/ => “Syncthing is a continuous file synchronization program.” 
What unwanted means, is up to the user and he/she/it is in authority for the data in the first place.
Thank your for the committed replies. Of course I want this option only for certain folders - containing only one database, not a global option. E.g. I use the same database for KeePass on Windows and Keepass2Android on my phone. Keepass2Android can add data that I don’t want to keep. That’s why I want it to be overwritten by default with the Windows file.
Twisting my words isn’t going to change this situation. If you want continuous override it’s scriptable.
If the device is not in authority of the data, it should be limited by filesystem permissions so that no local modifications could be made.
Not being able to modify stuff is a huge difference from thinking your modification happened just to later discover everything is nuked continiously.
It seems to me you are just too lazy to setup proper permissions and want a free joyride from syncthing in a form of a incredibly dangerous feature.
If I am wrong, justify why
I am amazed about the more and more dogmatic tone of the discussion. For certain cases I see this as an appropriate request. If the developers don’t want to consider it - okay.
It’s a snarky comment with no ill intentions which makes it look dogmatic I guess. I am not famous around for being a good communicator, but I just don’t see a good justification for what is being asked.
It’s not that we don’t want to consider it, it’s that we’ve considered and discussed it for literally years and have a quite ingrained understanding of the problems, solutions, desires and opinions by now. There’s 79 posts in just this thread, and there are many threads just like it. I understand that if you jump in now with a suggestion it seems like we’re brushing you off, but we’ve had this discussion since 2015.
Having to repeat the same arguments every few months when someone new comes along with the same questions gets tiring, hence why we’re now at essentially “not gonna happen, go away”.
And no, the fact that the request comes up with some frequency does not by itself mean that we are wrong and should implement it.