I recently run into an error with the web GUI on Linux (Fedora Workstation 38). It fails to open the webpage when I start syncthing via the terminal command or “Start Syncthing” in the app drawer. “Syncthing Web UI” does open it…
That’s where the real problem comes. I can open the web UI with the “Syncthing Web UI” app, or by typing the IP into my address bar. But it’s all plaintext.
Unlike the regular web UI it’s peppered with prompts like Restart needed: the configuration has been saved but not activated and Notice: {{err.when | date:"yyyy-MM-dd HH:mm:ss"}}: and many more. I can use Syncthing by clicking the buttons for pause, shut down, restart etc. But so many elements are completely broken and do not display the right information.
Troubleshooting: Clearing my browser cache, and restarting the computer have not worked.
What method of installation did you use to load Syncthing?
What is the specific version number of Syncthing that you’re running?
I always download the gzip file and run it that way. You will get varying results depending on if you installed it from the distro software repository or a different repository. Also check the version of the software that you have and make sure that it is the most recent because sometimes the software from a repository can be older.
For me, and most probably, The GUI works perfectly when you run the software this way.
I searched my installed software and there is no official Syncthing package in the Fedora repos or on Flathub, and although it seems plausible I’d install Syncthingy, none of the other packages were installed. My assumption is that I installed the 64-bit tar.gz.
I don’t know how to discover the version number because of course, the top button in the web UI just says Upgrade to {%version%}. So for now, I’m assuming it’s the second latest.
I’m running v1.23.7. I downloaded the version you mentioned there and ran syncthing within its folder when extracted, and nothing has happened. Opened the web UI to be sure and it’s the same as initially described. Edit: found config.xml, not sure why to rename it or in what context.
This hyperlink has the location of the configuration directory that the software uses and every time you do a clean install you want to remove this directory first.
It would be a very good idea prior to running the new latest version of the software to rename the whole configuration directory and let the new software create its own configuration file and certificates and such. The certificates are particular to the browser.
Based on your description of the problem, it sounds like your user profile, or at least Syncthing’s configuration, is corrupted. If there’s a bigger problem, it could also be affecting the software catalog.
From the command-line, output from the command dnf info syncthing:
Installed Packages
Name : syncthing
Version : 1.23.7
Release : 1.fc38
Architecture : x86_64
Size : 24 M
Source : syncthing-1.23.7-1.fc38.src.rpm
Repository : @System
From repo : updates
Summary : Continuous File Synchronization
URL : https://syncthing.net
License : MPL-2.0 AND Apache-2.0 AND BSD-2-Clause AND BSD-2-Clause-Views
: AND BSD-3-Clause AND CC-BY-3.0 AND ISC AND MIT AND MPL-2.0 AND
: OFL-1.1
Description : Syncthing replaces other file synchronization services with
: something open, trustworthy and decentralized. Your data is your
: data alone and you deserve to choose where it is stored, if it is
: shared with some third party and how it's transmitted over the
: Internet. Using syncthing, that control is returned to you.
:
: This package contains the syncthing client binary and systemd
: services.
If the command above doesn’t work, or doesn’t find the Syncthing package, purge the current catalog plus any cached packages with the following command:
dnf clean all
If Syncthing was installed from a RPM package, the following command will search the list of installed packages:
Thanks, the dnf command did have a result so that’s how I installed it. Earlier I searched in the software app which doesn’t seem to provide a full picture. From the Fedora package catalog it looks like they just recently updated their package to syncthing v1.24, so I will perform a system update and see if that helps. I’ll try your other advice and return here if that isn’t a solution.
The RPM version of the software and the downloaded G zip file both use the same configuration directory (i presume) and there are 2 different versions of the software. You would have needed to delete the configuration directory that the rpm Created before running the downloaded version from the websites for the first time.
This could result in confused config settings. That’s why we both pointed toward corrupt configuration settings. You can’t run one version of the software and then run a different version of the software using the same configuration directory. That is precisely what it seems is happening.
Actually there is usually no need to fiddle with the configuration directory when using Syncthing from different sources. The compiled binary is always the same. Just in case one version is newer and it brings a new config file format, then the config file is upgraded after making a backup copy automatically. Thus you can always return to the older version by renaming that backup to config.xml again, or by using the --allow-newer-config command line switch. The latter is usually safe, as there have been no incompatible changes in the file format recently.
Regarding your GUI troubles, what we need to investigate is the console output from Syncthing when you start it in a terminal. That will tell you what could be going wrong and if the service is even running at all. Make sure to stop any background service you might have configured to start Syncthing automatically, as two instances cannot use the same database and the younger one just quits. Your description of the GUI state indicates the service might not be running and your browser has only a part of the GUI source files cached.
Have you set the STGUIASSETS environment variable by any chance?
Actually there is usually no need to fiddle with the configuration directory when using Syncthing from different sources. The compiled binary is always the same. Just in case one version is newer and it brings a new config file format, then the config file is upgraded after making a backup copy automatically. Thus you can always return to the older version by renaming that backup to config.xml again, or by using the --allow-newer-config command line switch.
Thank you for this information I will make a note of it and the switch too.
I don’t think this was known and these switches were not used and alternating versions were executed.
The compiled binary is always the same.
Actually there are two distinctly different versions of the binary file. 1.23.7 and 1.24.0.
My suggestion was based upon my own past experience having installed two different versions that were not compatible with each other because one came from an outdated software repository and the other came from the website download area.
I was hoping that if this person deleted one of the two installations, the older one and also the configuration directory and only ran the new software it would create a new config file and everything would be happy.
I don’t ever use RPM distros so I know nothing about how to manipulate their packaging.
Of course these are different. But if you install Syncthing vX.YY.Z from an RPM or from GitHub, you can expect the two binaries to behave the same, especially regarding config file parsing. The only likely difference would be the version of the Go language and runtime that was used for building it.
Well, “incompatible” is what I tried to make clearer. Syncthing is really good at handling these config XML files, and there is only one simple version number that gets incremented when new elements are added / changed. Downgrading might lose some information if an element was renamed, but that hasn’t happened in recent times. But unless it complains about the missing --allow-newer-config switch, reading config files from a different version should never result in Syncthing not starting.
If the XML file is truly corrupted and Syncthing doesn’t start, it might be easier to fix it with a text editor, rather than setting up everything from scratch.
I’m very careful with such kind of advice. Deleting the whole config directory also removes the device certificate which defines the device ID. There is absolutely no way to regenerate that (which is the whole point of using cryptography here). So if the device is already connected to other devices, the newly generated device ID needs to be configured on each one, and all sharing settings re-done. That’s why I view the cert.pem and key.pem files as valuable data and avoid telling people to delete them unless they really want a completely fresh start.
Yes, I understand. In this case it appears to be a new installation that hasn’t begun working yet for the first time so I don’t think that is an issue here.
If the XML file is truly corrupted and Syncthing doesn’t start, it might be easier to fix it with a text editor, rather than setting up everything from scratch.
It might be easier for an experienced user but not for a new to syncthing novice user. I have deleted the XML file and recreated the file shares pretty quickly now that I have a good handle on how to do it and it for me would take less time than to try and figure out how to learn how to edit the config file and identify exactly what is corrupted and then fix it.
I’m slowly learning more and more from folks/helpers such as yourself.
I have definitely not set any variables including STGUIASSETS, I only use the web GUI.
The service seems to be running as I can start syncthing on another device and it’ll sync up with this computer. On this computer, which I often power off or restart, I’ll launch syncthing via a keyboard shortcut that runs syncthing in the terminal without opening a window for it. Usually I’d shut down syncthing after each sync and launch it the next time.
Re: the console output from the terminal. I ran syncthing and am told it’s running v1.24, and receive the warning that states (is another instance of syncthing running?). What this tells me is that syncthing is summoning the newer version I installed through the gzip file, but the older version installed through dnf is also present and possibly running.
Note this conflict between two versions cannot be the primary cause of my problem, because I only just installed 1.24 through the gzip after it was suggested in this forum.
Next, I would Try running syncthing with the --browser-only flag.
This will prevent Syncthing from trying to launch a second instance of the software it will just open the management console.
Opens the web UI in a browser for an already running Syncthing instance.
Step One should be to make sure you get yourself down to one server running. They are both trying to listen and serve requests on port 8384
After you choose one server, I still recommend my original thought. Don’t delete the configuration directory just rename the config file and let Syncthing 1.24 create a new one.
Then, if the problem goes away then it’s likely there is something wrong in the renamed config file. You can then compare the two files to each other and see if you can find where the problem is.
As you mentioned the problem preexisted the install of 1.24 so, a closer examination of the config file seems prudent.
Invalid or missing API key: If the API key in the configuration file is incorrect or missing, it can prevent the GUI from running. Make sure the API key is correctly set in the configuration file.
I ended up removing both the gzip download for syncthing and the rpm package (which has now updated to 1.24) and reinstalling syncthing through dnf (the rpm package again).
Upon re-logging-in, I opened the “Syncthing Web UI” icon and the web UI opens… same issues.
I also followed your suggestion and renamed config.xml to something else. Edit: I’ve compared the files and the original config file is ~10kb larger, containing details about each folder I’ve added. The new config file seems ‘stock’. As you said there is likely a bigger issue at play here.
Upon re-logging-in, I opened the “Syncthing Web UI” icon and the web UI opens… same issues.
I’m not sure what you mean when you say that you open the icon.
When you do a new clean install of Syncthing, it should automatically launch your web browser and open a tab to the management console.
What happens if you open firefox and then simply type in 127.0.0.1:8384 ?
That should bring you to the management console if everything is installed and running properly.
Unfortunately, beyond where we are now, we have exhausted my troubleshooting skill set. I don’t know what to suggest next.
I’ve also never used a version of Syncthing installed via RPM.
The only installations that I have done are manually downloading the software and unzipping it into a new folder and simply running ./syncthing
Somebody with more experience in this area is going to need to chime in and offer some expertise.
Great. Now don’t change anything else for the time being – no updates, no new software installs, no configuration changes, etc.
Okay, I think we need a shared point of reference otherwise there are going to be triple digit posts on this thread.
I’m assuming that you’re using the default Fedora 38 “Workstation” edition, and not one of the many “spins” such as “Silverblue”, alternate desktop environments (e.g. Xfce, LXDE) and so on.
As mentioned above, don’t make any new changes until otherwise noted.
Reboot the computer.
Log in – but do not launch/start anything other than what is auto-started during login.
Open a terminal window (Fedora 38’s GNOME Terminal is fine).
Now, issue the command:
ps -ef | grep syncthing
Does the output look something like this? (user will be your login name):
user 3138 3036 0 09:16 ? 00:00:00 /usr/bin/syncthing -no-browser
user 3143 3138 0 09:16 ? 00:01:01 /usr/bin/syncthing -no-browser
If it doesn’t, open another terminal window and issue the command:
syncthing --no-browser
Next, return to the first terminal window and issue the command:
curl -s http://127.0.0.1:8384/ | md5sum
Does the output match this?:
34072724a9517da55e89bd24aca80cf8 -
(The HTML/JavaScript/CSS for the web GUI homepage in Syncthing 1.24.0 has the MD5 hash 34072724a9517da55e89bd24aca80cf8.)
On Fedora, Ubuntu and other distros that use the GNOME desktop environment, when a user taps the “super key” (aka., “Windows” key on a keyboard), or clicks the “Activities” hotspot in the upper left corner of the screen, it brings up a search box near the top of the screen.
As a user types into the search box, GNOME Shell finds matches in the known list of installed software. Depending on what’s installed, just a simple “sy” might be enough to pull up launch options that include Syncthing.
