Access to remote gui only worked briefly

Yesterday was my first introduction to syncthing and I was lucky to make huge progress. I have a linux box and linux server to sync. For a spell I was able to browse localhost:9090 on the client and see the server GUI after running this on the client: ssh -L 9090: servername.

Then I set up both the client and the server to auto-start and run a daemon in the background, activating them this way (myuserid is substituted):

systemctl --user enable syncthing.service
systemctl --user start syncthing.service

sudo systemctl enable syncthing@myuserid.service
sudo systemctl start syncthing@myuserid.service

[Note: the config files are already installed due to using the Ubuntu/debian package for syncthing]

Syncing client <-> server is working perfectly. But now when I ssh -N -L 9090: myusername@servername I get channel 3: open failed: connect failed: Connection refused and localhost:9090 won’t come up.

Here is the output from systemctl status syncthing@myuserid.service when run on the server:

syncthing@myuserid.service - Syncthing - Open Source Continuous File Synchronization for myuserid
   Loaded: loaded (/lib/systemd/system/syncthing@.service; indirect; vendor preset: enabled)
   Active: active (running) since Mon 2020-06-01 11:45:51 UTC; 15min ago
     Docs: man:syncthing(1)
 Main PID: 4584 (syncthing)
    Tasks: 15 (limit: 1121)
   CGroup: /system.slice/system-syncthing.slice/syncthing@myuserid.service
           ├─4584 /usr/bin/syncthing -no-browser -no-restart -logflags=0
           └─4590 /usr/bin/syncthing -no-browser -no-restart -logflags=0

Jun 01 11:45:52 ip-172-26-14-114 syncthing[4584]: [HFMFU] INFO: Using discovery server
Jun 01 11:45:52 ip-xxxx syncthing[4584]: [HFMFU] INFO: Ready to synchronize "Default Folder" (default) (sendreceive)
Jun 01 11:45:52 ip-xxxx syncthing[4584]: [HFMFU] INFO: Relay listener (dynamic+ star
Jun 01 11:45:52 ip-xxxx syncthing[4584]: [HFMFU] INFO: GUI and API listening on
Jun 01 11:45:52 ip-xxxx syncthing[4584]: [HFMFU] INFO: Access the GUI via the following URL:
Jun 01 11:45:52 ip-xxxx syncthing[4584]: [HFMFU] INFO: TCP listener ([::]:33685) starting
Jun 01 11:45:52 ip-xxxx syncthing[4584]: [HFMFU] INFO: My name is "ip-xxxx"
Jun 01 11:45:52 ip-xxxx syncthing[4584]: [HFMFU] INFO: Completed initial scan of sendreceive folder "Default Folder" (defa
Jun 01 11:46:03 ip-xxxx syncthing[4584]: [HFMFU] INFO: Detected 0 NAT services
Jun 01 11:46:28 ip-xxxx syncthing[4584]: [HFMFU] INFO: Joined relay relay://xxxx:22067

I also tried ssh -L 9090: servername but localhost:9090 shows the server as not having shared any folders (which is incorrect because syncing is actually working).

Note: The GUI to the client, running on the client, shows the server disconnected even though that is not the case.

Any help much appreciated.

That usually means you have another instance of syncthing running, thus port 8384 is already used and another one is chosen. That’s consistent with the incorrect info displayed. I’d guess you set up things with another user than you are running now. Check with ps -e | grep syncthing if there’s indeed another instance running.

1 Like

Thank you. I do see two /usr/bin/syncthing -no-browser -no-restart -logflags=0 after running ps. I’m trying now to figure out why the systemd setup triggered two of these.

systemd list-units | grep syncthing and/or systemd --user list-units | grep syncthing might provide you that info.

list-units is not an option for systemd on my Ubuntu 18.04 server.

I did stop and disable the service, then re-enabled and started again, and again saw 2 lines in the ps output. I used both @userid.service and @userid in the commands since I don’t know the difference between these two (enabling and disabling between each of those two tries).

In / I see lots of instances of syncthing in /sys/kernel, /etc/systemd/.../syncthing (one instance there), /run/systemd/...systemd, /sys/fs/cgroup/....

Two processes are expected, there’s a parent and child process per syncthing instance. ps auxf shows you the parent-child relationships which should make that clear. And what started the processes.

They are the same thing.

1 Like

Ah yes here’s that output:

systemd+   619  0.0  0.3 141932  3396 ?        Ssl  16:35   0:00 /lib/systemd/systemd-timesyncd
ubuntu    1717  0.0  0.1  14852  1088 pts/0    S+   17:39   0:00              \_ grep --color=auto sync
userid    1540  0.0  1.3 120692 13740 ?        Ssl  16:43   0:00 /usr/bin/syncthing -no-browser -no-restart -logflags=0
userid    1546  0.1  4.1 122548 41876 ?        SNl  16:43   0:04  \_ /usr/bin/syncthing -no-browser -no-restart -logflags=0

Any suggestion for the next diagnosis to try to make will be appreciated.

Ok, so just one instance running now - all good on that front.

To get back to port 8384, just go to settings>gui and adjust the listen address thus.

Then what problem remains?

1 Like

I edited the user .config/syncthing/config.xml on the server. I changed an aborted try of 42003 to 8384 and restarted services. Now I can launch the web browser gui to both the local (client) machine and to the server. But the client machine says the server is disconnected, and the server gui reports that the server has no remote devices (this despite proper working of synchronization in the background). I set up the remote gui using ssh -L 9090: userid@servername and didn’t edit any api tokens inside of any config.xml.

systemctl status syncthing@userid reports gui listening on

What do you mean by that? If there’s just one Syncthing instance and it doesn’t have remote devices, it can’t be syncing.

That syncthing chose a different port looks to me like you at first ran syncthing under a different user, and that’s what the other device connected to first. Compare the device id of the server with the remote device id on the client, they would be different then. You could find those old configs and copy them to the correct user, or you just setup again now with the correct user.

1 Like

I logged into the server as superuser and ran syncthing --no-browser --device-id and double checked that the device-id is exactly what is showing in the GUI on the client for the server’s device-id. But when I look at the remote GUI to the server and ask it to report its ID I get a totally different device-id from what is reported from the command line running on the server. It turns out to be the device-id that I get from running syncthing --no-browser -device-id as user on the server matches what what the remote GUI reports for the server device-id.

So you think I’ve just confused the device-id on the server between the user (me) and the superuser?

Not the device id, but you seem to think it doesn’t matter what user you run syncthingas: You ran syncthing as root now, which you generally shouldn’t do, and didn’t do just before when you started it with sudo systemctl start syncthing@myuserid.service, i.e. as user “myuserid” (which I assume is not root). You now have two configs, one below /root/ and one in '/home/youruser/. I suggest you remove the one under /root/`, remove the remote device on your “client” and then add then run Syncthing with systemd and configure it in that instance (not root).

1 Like

Will do. Thank you! I changed the server device-id in the client web gui and all is well!

I moved to syncthing from the unison world where nothing operates on the system level, so I wasn’t used to this distinction. (I could not get over unison compatibility problems across Linux versions, and found file permission problems when using unison on snap.) I’m loving syncthing so far, especially thanks to your great community support.

1 Like

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