I’m running a syncthing server on my synology NAS (via the community packages) for quite a while now without any Problems. The version running on the server is 1.23.4-29 (latest available via community packages). I have multiple devices connected to the server all windows devices running 1.29.0 and all android devices running 1.28.1.
Sync is running flawless but I can’t access the GUI of my server, any suggestions?
It’s not a login problem, i can’t connect to the GUI. My browser says ERR_EMPTY_RESPONSE
Gotcha. Sorry for the misunderstanding.
I don’t know much about Synology. Are there two Syncthing processes running? Two is normal.
Sounds like a firewall problem. Have you checked the related settings in DSM?
There is no firewall activated on the NAS and I’m in the local network, not accessing from remote. But I’ll check on my opnsense and report back
If tried now with different devices, I turned off windows firewall but nothing works. I cheched other services hosted on my NAS (Joplin, Unifi) they all work like before. And just to be clear, syncthing server GUI worked in this config for years, I don’t know what broke it.
Are you sure the DSM firewall is inactive? Is it DSM 6 or 7? The package by default installs firewall rules to open up the used ports automatically. Note that the Windows firewall on your PC is most probably not related to this problem.
Can you see any logs on the DSM for the Syncthing service? Either a log file somewhere in /var/app/... or in the System Log app, for when the service is started.
Do you have access to the console? Have you checked that syncthing is actually running as a process (via ps)?
My gut feeling says it might have something to do with (not) using TLS, but the “empty response” error code is definitely strange.
And did you try restarting the service from the Package Center app yet? Or the whole DiskStation?
all mainline official syncthing channel and normal windows10 x64, firefox x64, both being non-english, but windows usernames and paths without any fancy special characters, all being running from inside the documents folder of the windows user itself. all working normally until recent syncthing release. here are the steps:
I think there is an issue with 1.29.0 in contrast to the previous 1.28.x version,
me being here on win10 x64, firefox for webaccess of syncthing gui. with password. no ssl/https enabled.
when reverting back to the .exe of 1.28.x of synchting my login into syncthing web gui works immediately. when using/letting/allowing it to re-upgrade back to 1.29.0 again it refuses my very simple username (e.g. alpha chars lowercase username of 7 characters and password is digits only 4 characters)
the configuration .xml file is unchanged since early november last year.
there seems something wrong here. either how the password is being interpreted read from xml file or how the webbrowser (firefox x64 on windows x64, all vanilla official stuff) is submitting or encoding the data or something?
the error message inside the password dialog (webpage) shows a red error line to look for syncthing log files as for the username and or the password being wrong it says. I dont have logs that show me more about this error or can not find them or dont have the appropriate loglevel enabled just yet i guess. anyhow. downgrade restores login functionality immediately. some bug.
bug?
i have the same password on a different windows10 x64 machine where the username is longer but also all lowercase chars only where it doesnt have a problem with being on 1.29.0 which is odd.
anyone? thanks.
Only relevant info I can add is that the “look at logs” type error indicates an HTTP error or server error of some kind. It is different and distinct from “wrong credentials”, so it’s not wrong password but rather something broken.
i am not at the affected machine right now I can not add much info, is further info needed by the developers? maybe it some new go compiler stuff or so that changed something fundamentally?
“everything else” on my side is the same as only swapping out the newer .exe for the previous .exe immediately fixes the situation on this windows machine.
do we need logs and which logs do I enable for this exactly for you guys to be able to find out more? thanks.
Since you’re on Windows there should be a log file in the directory where Syncthing keeps config etc. Take a look in that one. Maybe the browser console also has some relevant information. Currently I have no idea what might be the problem.
remembering from some hours ago, I even started the windows exe process manually without parameters on the command line (cmd box) and it printed out those standard stuff of relays being joind and peers being found and connected and folders being synchronized etc, but no log line appeared in that .log file (nor on console printout) when entering the credentials and doing the log-in situation.
will report back when i can manage the windows machine again later. thanks.
Hello, I have similar problems to login to the syncthing-GUI on a synology NAS. The installation is running V1.29.0, did a “self update” last days.
The login is refused but no information why in “/volume1/@appdata/syncthing/syncthing.log”
Even after a “syncthing generate --gui-password=syncthing --gui-user=syncthing” a login is not possible: “wrong username or password”…
Seems a problem of version 1.29.0?
Regards Ralf
so what debugging facilities do we turn on to get closer to this bug and behavior? i am at the affected windows x64 (win10) machine right now. its pinned down at downgraded version v1.28.1, Windows (64-bit Intel/AMD) official sycnthing build.
thanks.
I don’t think this is a universal issue. For the record, I’ve tried to reproduce locally with a clean configuration of Syncthing v1.28.x and v1.29.0, but everything has been working as expected so far.
Start by showing the failed request in a browser debug console. Presumably the login request fails somehow.
i am not a huge webdeveloper but I kinda find it a bit hard to make sense of the logs.
in firefox on windows, i can trigger the webconsole debugging and logging stuff via:
ctrl+shift+i
then i go there into the network analysis area (tab?) and deactivate cache there on the right side of the bar, and using the cogwheel symbol at the very right side i can deactivate the flushing of logs as far as I make sense of it, only this way I see the very first log line with the actual http POST line when doing the log-in
actually calling the localhost syncthing page with the log-in gui and flushing all the logs first, and starting from there.
so on the normally functioning 1.28.1 there is an inial POST after submitting the entered username and password.
and to this POST there are answer headers from the localhost webserver, that immediately bring in session ticket cookie via the header or how all this works. (set-cookie with session id as value…)
oh btw, I set the throttling to GPRS speed so that I can actually watch stuff happening a bit.
after this initial POST and its response headers there are only GETs after this as far as I can briefly make sense of the endless requests, my syncthing situation is rather large here it has tens of folder objects and tens of clients to sync to.
anyhow, is this maybe the actual only line to watch for? then I can go over to upgrading 1.29.0 and see the same stuff there.
okay more info, my problem with 1.29.0 vanished after this experiment which went on as follows:
so inside (firefox anon window) this 1.28.1 viewing the web developer debugging stuff, I had previously disabled the auto-update of the stable release channel completely.
so there was this blue button like area at the top of the 1.28.1 syncthing asking me to upgrade to 1.29.0 via this button. apparently I was logged into the synchting gui normally for this step with the syncthing web user which workes for 1.28.1
so after the speedy update to 1.29.0 the web gui came back up still being inside the anon window of firefox and the user was immedisately logged in. even logging out and re-logging in doesnt bring up the trouble any more.
even closing firefox completely and using non-anon window/tab works now on this same previously affected machine now being on 1.29.0
maybe it is/was? some caching corruption or something with firefox? as the web developer debugging console allows to disable caching and what not? or some cookies settings headers invalidation of caches or what not?
i can only list so many buzzwords and brief concepts i have come across in my web life experience, sorry.
so right now my log-in problem with 1.29.0 is gone.
weird. thanks for all the info.