Can't access v1.26.0 on localhost

[tomasz86]

@bt90

The question is how the browser is able to get past the login screen which is supposed to intercept this.

What if the browser was already logged in via basic authentication before upgrading Syncthing?

[AudriusButkevicius]

That reload should now redirect to the login page. Previously the reload toggled the basic auth prompt.

[bt90]

The browser might cache the basic auth credentials, but that shouldn’t be a problem as we still accept them.

[Ione_15]

Experiencing the same issue on Android 13 with syncthing 1.26.0 from PlayStore with Chrome disabled and Firefox installed.

[Andy (Andreas Kaelber)]

On Windows PC Portable installation the same Firefox refreshing during all time, Chrome and Edge are running smoothly.

But is not on Synology with v1.26.0 and native SynoComm and two Docker instances of Syncthing and Linuxserver.

[bt90]

Could you check the network tab of the browser dev tools?

[Brerlapn]

I just had the same problem since the last update on my machine running Ubuntu 22.04.3 LTS using Firefox. No issues on my Windows machines.

I removed the cookies for 127.0.0.1 and it resolved the issue.

What’s odd was that aside from the constantly refreshing UI page in the browser, when I went to the command line to check systemctl status it said it couldn’t find syncthing (syncthing.service I think was the precise one that the help forums had said to check status for).

[gadget]

@Brerlapn

What’s odd was that aside from the constantly refreshing UI page in the browser, when I went to the command line to check systemctl status it said it couldn’t find syncthing (syncthing.service I think was the precise one that the help forums had said to check status for).

systemctl status syncthing.service is the long-form syntax. “service” is assumed if not specified, e.g., systemctl status syncthing.

But either way, it’ll simply say “Unit syncthing.service could not be found.” because Syncthing runs as a user-level service.

So as the user who is running Syncthing, include the parameter --user like this:

systemctl --user status syncthing

But if Syncthing is started at the system level for a user named “neo”:

systemctl status syncthing@neo

(The downside to starting at the system level is that the specified user cannot stop the service.)

[Brerlapn]

Thanks, this is very helpful! Sadly most of my knowledge of those kinds of process nuances are for Windows (due to work), but I’ve been building my sysadmin notebook with items like this as I build out my home lab.