Well that makes three oddities. I too dislike desktop apps (one reason why I just removed syncthing-gtk rather than find out what was wrong). I always use the web browser… only mine is on localhost:8080. Any idea why?
How did you install it?
I mean I changed the defaults for discovery server so I don’t broadcast to the internet, same for my sync relay service - but the local webservice for the client has always been on port 8384 - and the counterpart involved here is actually a Windows server - simply downloaded and installed from syncthing - so the use of port 8080 - that is a mystery to me.
Wait a moment - that means the service is running … no matter the port …
I can’t guess how it might have happened, but it seems like Syncthing is listening to a typical loopback address used for a webserver. Do you you have a local webserver active?
localhost:8384 is the default port that Syncthing should use.
I’m not 100%, it was probably as a dependency of syncthing-gtk, but it was a long time ago (many years) so I can’t remember. Certainly it wasn’t independently, it was either direct from the official repositories or from syncthing-gtk.
$ pacman -Qi syncthing
Name : syncthing
Version : 1.27.7-1
Description : Open Source Continuous Replication / Cluster Synchronization Thing
Architecture : x86_64
URL : https://syncthing.net/
Licenses : MPL-2.0
Groups : None
Provides : None
Depends On : glibc
Optional Deps : None
Required By : None
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 23.03 MiB
Packager : Caleb Maclennan <alerque@archlinux.org>
Build Date : Wed 08 May 2024 08:49:34 BST
Install Date : Wed 22 May 2024 13:08:05 BST
Install Reason : Explicitly installed
Install Script : Yes
Validated By : Signature
I meant to say it always has been on 8080.
But yes, I can run syncthing just using syncthing. I just can’t get it to autostart on boot>login. It stops at shutdown and only restarts when I open it from the console.
If it is running on port 8080 - then something strange is going on.
I cannot say what - but some kind of proxy is in play …
The safest way forward is to remove everything syncthing related - you can keep your folders - but service related … restart your system - only install the repo package - syncthing - enable the service - the user version - not the global version - check the permissions on the folders.
I only know tthat syncthing defaults to 8384 - it is possible to change - though rarely needed.
You likely have a configuration in ~/.config/syncthing
the gui port is defined in config.xml - so it may have been set by the gtk installer
<gui enabled="true" tls="false" debugging="false" sendBasicAuthPrompt="false">
<address>127.0.0.1:8384</address>
<password>bla-bla</password>
<apikey>more-bla</apikey>
<theme>dark</theme>
</gui>
So this is not the cause unless you have some other service claiming the port - which will make it first requested first served - perhaps change it to 8384 - and restart the service
Yep. ~/.config/syncthing/config.xml gives…
<gui enabled="true" tls="false" debugging="false" sendBasicAuthPrompt="false">
<address>127.0.0.1:8080</address>
and
<options>
<listenAddress>default</listenAddress>
<globalAnnounceServer>default</globalAnnounceServer>
You can change the default in the GUI → Actions → Settings → GUI tab
So if you have a conflicting service - you would definately benefit from changing the port - as 8384 is the default - it is as good as any.
Thanks. I’ll do that. No idea what happened, but a little web search found I’m not the only one
https://www.reddit.com/r/Syncthing/comments/j5bdwi/syncthing_running_on_port_8080_instead_of_8384/
And from this…
…I’m beginning to piece together the puzzle. It seems syncthing used to use 8080 (possibly) and it’s not always changed because the port settings are in the local config which isn’t updated when syncthing updates?
I’m switching to 8384 now. Not likely to impact the original problem though, but maybe tangentially related.
I’m loathe to remove syncthing entirely because it takes so long to set up all the syncs, but if need be, I’ll have to resort to that.
I am not sure you need to - when changing to 8384
Change the port, reboot, and it should continue as before. If a port conflict was the problem, it may even startup as expected now, if the other settings are in place.
Done. All is well.
However…
systemctl --user daemon-reload
systemctl --user enable --now syncthing.service
still yields
Failed to enable unit: Unit file /home/{me}/.config/systemd/user/default.target.wants/syncthing.service does not exist.
then list the log
systemctl --user status syncthing.service
Have you created the file manually? Perhaps is placed in the wrong folder?
Perhaps it does not exist?
/usr/lib/systemd/user/syncthing.service
On a healthy system a symlink is created in your local config folder - just a though does sthe folder exist
~/.config/systemd/user/default.target.wants
$ tree .config/systemd
.config/systemd
└── user
├── check-aur.service
├── check-aur.timer
├── default.target.wants
│ ├── modprobed-db.service -> /usr/lib/systemd/user/modprobed-db.service
│ └── syncthing.service -> /usr/lib/systemd/user/syncthing.service
├── protonvpn_reconnect.service
└── timers.target.wants
└── check-aur.timer -> /home/fh/.config/systemd/user/check-aur.timer
That’s going to give a really confusing result right now because I started syncthing manually. I’m at work right now, so I need it running, I’ll shut down the computer in a bit and see what it yields from clean reboot without a manual start of syncthing.
cat /usr/lib/systemd/user/syncthing.service
[Unit]
Description=Syncthing - Open Source Continuous File Synchronization
Documentation=man:syncthing(1)
StartLimitIntervalSec=60
StartLimitBurst=4
[Service]
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4
# Hardening
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true
# Elevated permissions to sync ownership (disabled by default),
# see https://docs.syncthing.net/advanced/folder-sync-ownership
#AmbientCapabilities=CAP_CHOWN CAP_FOWNER
[Install]
WantedBy=default.target
and
cat ~/.config/systemd/user/syncthing.service
[Unit]
Description=Syncthing - Open Source Continuous File Synchronization
Documentation=man:syncthing(1)
StartLimitIntervalSec=60
StartLimitBurst=4
[Service]
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4
# Hardening
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true
# Elevated permissions to sync ownership (disabled by default),
# see https://docs.syncthing.net/advanced/folder-sync-ownership
#AmbientCapabilities=CAP_CHOWN CAP_FOWNER
[Install]
WantedBy=default.target
You shouldn’t need it there - remove it - the file in /usr/lib/systemd does the work
Ah. So the Syncthing docs are a little confusing here. They say…
From git location copy the
syncthing.servicefile into the load path of the user instance. To do this without root privileges you can just use this folder under your home directory:~/.config/systemd/user/.
I’ll try that later when I can get a clean computer without syncthing already running.
Thanks ever so much for you help.
The offical synthing docs cannot possilby cover all usecases.
The Arch Linux maintainers may have abstracted this step by adding the file in /usr/lib/systemd/user - and the Arch Linux docs is therefore simplified compared to the official doc - the K.I.S.S at work 
No joy.
Here’s what I’ve done.
-
Reboot
-
Test there’s no syncthing running - nothing on Localhost:8384 (also nothing on 8080)
systemctl --user status syncthing
○ syncthing.service - Syncthing - Open Source Continuous File Synchronization
Loaded: loaded (/usr/lib/systemd/user/syncthing.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:syncthing(1)
- Check syncthing.service has been removed from ~/.config
cat ~/.config/systemd/user/syncthing.service
cat: ~/.config/systemd/user/syncthing.service: No such file or directory
- Check service unit is in /usr/lib/systemd/user
cat /usr/lib/systemd/user/syncthing.service
[Unit]
Description=Syncthing - Open Source Continuous File Synchronization
Documentation=man:syncthing(1)
StartLimitIntervalSec=60
StartLimitBurst=4
[Service]
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4
# Hardening
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true
# Elevated permissions to sync ownership (disabled by default),
# see https://docs.syncthing.net/advanced/folder-sync-ownership
#AmbientCapabilities=CAP_CHOWN CAP_FOWNER
[Install]
WantedBy=default.target
- Reload daemons just in case
systemctl --user daemon-reload
- Enable syncthing
systemctl --user enable --now syncthing
Failed to enable unit: Unit file /home/{me}/.config/systemd/user/default.target.wants/syncthing.service does not exist.
What did I miss?
Did you created the default.target.wants folder?
No. That step isn’t written in any of the instructions.
mkdir ~/.config/systemd/user/default.target.wants
mkdir: cannot create directory ‘/home/{me}/.config/systemd/user/default.target.wants’: Permission denied
… which is odd, so…
ls -alg ~/.config/systemd
total 20
drwxr-xr-x 3 root 4096 Aug 8 2019 .
drwxr-xr-x 74 {me} 12288 May 26 17:13 ..
drwxr-xr-x 3 root 4096 May 26 17:12 user
… shouldn’t all directories in ~/ be owned by me? Is this the problem?
Yes. This looks wrong and is probably the reason why the missing folder is not created by the enable command.
1 Like