I did look for this answer but not found anything. I’m just setting up Syncthing via Docker and using my Android phone as the device. I assumed at point of install that the Android would be a client only but it seems that it’s actually running a server. My question is that if I use the option to sync over the mobile data plan then I’m essentially opening up a web login to the internet that would connect directly to my phone. If a user uses a terrible password for the GUI, surely that opens them up to an attack vector no? Is there any way to configure Syncthing as just a client, without the Server element of it?
I don’t think there is a concept of server-client in Syncthing. Also, the GUI is limited to local access by default, so you shouldn’t worry about that anyway. You can verify it yourself by looking up the GUI listen address in the app settings, which should be set to 127.0.0.1:8384.
For this guide let’s assume you have two machines between which you want to synchronise files. In keeping with Syncthing terminology they are going to be called “devices” in the rest of the documentation. The “local device” is the one you are configuring, viewing status for, etc., while the “remote device” is the other machine.
The default listening address is 127.0.0.1:8384, so you can only access the GUI from the same machine. This is for security reasons. To access it from another computer, change the GUI listen address option in the web GUI from 127.0.0.1:8384 to 0.0.0.0:8384
This isn’t applicable to the Android app though . The address must be changed in the app’s settings, and after https://forum.syncthing.net/t/accidently-changed-ip/21671, I’d now be wary about even touching it in the Web GUI at all.
I just changed it to 0.0.0.0:8384 in the Web GUI and after restarting the value also changed in app settings. It seems to work the other way around too.
Hmm, I’m not sure this is the intended behaviour, as I do remember the app overriding the GUI setting in the past, but it was a long time ago and I may not remember the actual situation correctly. This is a problem though, because it means that if you set the address to an invalid value in the Web GUI, then the app will break requiring reinstallation, which is exactly what happened in the other topic.
In relation to this, there is also a quirk where you can set the address to :8384 which in the Web GUI automatically translates to 0.0.0.0:8384, however this doesn’t work in the app which requires 0.0.0.0:8384 explicitly.
I can confirm that I too broke access when just removing the address altogether to see what happened. Raises the question of why it’s even an accessible option given it can break the app and isn’t really designed to be changed. If you’re coming from the angle of it being locked to the loopback address in the interests of preventing access via the LAN assigned IP, then why allow access to it at all?
Which makes me ponder, if I add my phone’s assigned LAN address or better still the mobile network assigned IP to that listener using the same port, what happens? A test for later maybe.
So if I assign my LAN IP address and the default listening port, I can get to my GUI running on my phone. No idea what login creds are yet as I’m just starting to play.
Next I took my mobile data assigned external IP and assigned that with the default port in the app. Relaunching the app causes the expected failure. Need to clear data outside of app to allow reset and set it back to loopback address.
Not sure it’s really a big deal I guess. Why anyone would want to connect to their phone over their LAN, I can’t think. Still, if it’s not supposed to be changed, I’d at least hide it behind a “break it you buy it” warning screen.
It sounds like that app needs some fixing then. At the very least, it should be possible to modify the address in the app settings regardless of whether Syncthing itself is accessible or not due to a wrong or missing one.
I’d say it actually makes the most sense on Android specifically, because then you’re able to operate the Web GUI from a desktop computer on a large screen instead of struggling with it on the phone itself. That’s how I access and configure it myself basically all the time.
I agreee Tomas, its always a good idea to be able get back into the UI and fix any typo you made.
I have two suggestions if i may, on how it would be possible to mitigate the proplem:
On saving the IP section of the config UI, run the same logic that breaks if the IP is incorrect and provide feedback to the User that this IP is incorrect and will result in a broken UI, before restarting th ewhole app.
If the address settings crash the app, then reset (better if this could be temporary) to use the setup defaults to allow everything to start and be accessible again. This should be the default action across all devices, but particularly on android, where most people don’t have access to the filesystem to edit config files.
#2 could be taken a step further by having a last know good configuration file. if the app crashes, open the last know good config file and continue. this would solve alot of unknown problems when the app crashes for something the user has done to crash the app.
Functionally ST is awesome, its just complicated to get started with. reducing the possiblities for stuff-ups can only make it easier to use by the inexperienced.
Im just a hack, throwing in my 2cents worth of opinions
. The address must be changed in the app’s settings, and after 
