GUI address differs between service and config file (Linux, `systemd`)

Hello. I’m debugging a local CSRF issue (more here) and I’ve found a mismatch with the GUI address in my case.

== STR ==

I’m using a fully-patched Ubuntu 20.04LTS server:

$ uname -a
Linux darwin 5.4.0-139-generic #156-Ubuntu SMP Fri Jan 20 17:27:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

I’ve installed via the Syncthing .deb route, and I’m using v1.23.1:

$ /usr/bin/syncthing -version
syncthing v1.23.1 "Fermium Flea" (go1.19.5 linux-amd64) deb@build.syncthing.net 2023-01-16 03:48:02 UTC [noupgrade]

At this stage, there is just the app installed – no service file, no config, no customisations – literally just the app installed via .deb.

I created a user called syncthing with sudo rights (but no ssh/login rights) for storing configs and so on:

$ sudo adduser syncthing --gecos "" --ingroup sudo

I created a service file based on the sycnthing@.service (from here):

$ cat /etc/systemd/system/syncthing@syncthing.service
[Unit]
Description=Syncthing - Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
StartLimitIntervalSec=60
StartLimitBurst=4

[Service]
User=%i
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0 --gui-address=0.0.0.0:8384
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

# Hardening
ProtectSystem=full
PrivateTmp=true
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=multi-user.target

There is one change between the stock service file and the one above: I have added --gui-address=0.0.0.0:8384 to ExecStart because I’m proxying with Nginx to an external address (with htpasswd auth). I found that flag here.

I set up the new service file, start it, and check the status:

sudo systemctl daemon-reload \
&& sudo systemctl enable syncthing@syncthing \
&& sudo systemctl start syncthing@syncthing \
&& sudo systemctl status syncthing@syncthing

…and the service appears to be running (public IPv4 obfuscated:

$ sudo systemctl status syncthing@syncthing
● syncthing@syncthing.service - Syncthing - Open Source Continuous File Synchronization for syncthing
     Loaded: loaded (/etc/systemd/system/syncthing@syncthing.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-02-17 15:56:20 UTC; 1min 0s ago
       Docs: man:syncthing(1)
   Main PID: 2219 (syncthing)
      Tasks: 14 (limit: 2337)
     Memory: 40.1M
     CGroup: /system.slice/system-syncthing.slice/syncthing@syncthing.service
             ├─2219 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0 --gui-address=0.0.0.0:8384
             └─2239 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0 --gui-address=0.0.0.0:8384

Feb 17 15:56:22 darwin syncthing[2219]: [GTYLN] INFO: Loading HTTPS certificate: open /home/syncthing/.config/syncthing/https-cert.pem: no such file or directory
Feb 17 15:56:22 darwin syncthing[2219]: [GTYLN] INFO: Creating new HTTPS certificate
Feb 17 15:56:22 darwin syncthing[2219]: [GTYLN] INFO: GUI and API listening on [::]:8384
Feb 17 15:56:22 darwin syncthing[2219]: [GTYLN] INFO: Access the GUI via the following URL: http://127.0.0.1:8384/
Feb 17 15:56:22 darwin syncthing[2219]: [GTYLN] INFO: My name is "darwin"
Feb 17 15:56:22 darwin syncthing[2219]: [GTYLN] INFO: Completed initial scan of sendreceive folder "Default Folder" (default)
Feb 17 15:56:31 darwin syncthing[2219]: [GTYLN] INFO: quic://0.0.0.0:22000 detected NAT type: Symmetric UDP firewall
Feb 17 15:56:31 darwin syncthing[2219]: [GTYLN] INFO: quic://0.0.0.0:22000 resolved external address quic://192.0.2.1:22000 (via stun.syncthing.net:3478)
Feb 17 15:56:32 darwin syncthing[2219]: [GTYLN] INFO: Detected 0 NAT services
Feb 17 15:56:54 darwin syncthing[2219]: [GTYLN] INFO: Joined relay relay://192.0.2.2:22067

The GUI appears to be bound to [::] on the IPv6 side, and 127.0.0.1 on the IPv4 side:

Feb 17 15:56:22 darwin syncthing[2219]: [GTYLN] INFO: GUI and API listening on [::]:8384
Feb 17 15:56:22 darwin syncthing[2219]: [GTYLN] INFO: Access the GUI via the following URL: http://127.0.0.1:8384/

If I curl http://127.0.0.1:8384 I get the GUI markup code (which follows, since the service status output above says as much). The config file also lists 127.0.0.1:8384 as the GUI address (which follows):

    <gui enabled="true" tls="false" debugging="false">
        <address>127.0.0.1:8384</address>
        <apikey>DSYyyyyyTsxp5rUJNKZ2CsxF42N6CjTE</apikey>
        <theme>default</theme>
    </gui>

Edit: the API key is no longer valid, I’ve restored the server snapshot, so no implications for sharing here.

How can I force the GUI to use 0.0.0.0:8384 in the service file, please?

Thank you for reading.

GUI and API listening on [::]:8384

Your syncthing installation is already properly configured. [::] implies 0.0.0.0.

For the sake of simplicity, I would recommend to install syncthing from our apt repository:

https://apt.syncthing.net/

There’s also no need to edit the service file to adjust the GUI address. Simply edit the XML configuration and restart syncthing :wink:

2 Likes

Thank you @bt90 – I’ll do that. I appreciate your assistance!

Note that Syncthing’s DEB package includes a systemd unit file that’s installed at /usr/lib/systemd/user/syncthing so extra care needs to be taken to avoid conflicting unit files and/or inadvertently loading a different one.

Where did you place your custom unit file?

According to the output you posted from the command systemctl status syncthing@syncthing, systemd is loading the unit file /etc/systemd/system/syncthing@syncthing.service.

Is /etc/systemd/system/syncthing@syncthing.service a symbolic link to /usr/lib/systemd/user/syncthing?

3 Likes

Thank you @gadget - you were right with the service file observation. I had a duplicate service file that was causing the OP issue and looks like the root case for my first issue as well.

I am most grateful, thank you.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.