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:127.0.0.1:8384 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):
[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:127.0.0.1:8384 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 https://discovery-v6.syncthing.net/v2/?noloo
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+https://relays.syncthing.net/endpoint) star
Jun 01 11:45:52 ip-xxxx syncthing[4584]: [HFMFU] INFO: GUI and API listening on 127.0.0.1:42003
Jun 01 11:45:52 ip-xxxx syncthing[4584]: [HFMFU] INFO: Access the GUI via the following URL: http://127.0.0.1:42003/
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:127.0.0.1:42003 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.
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.
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.
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.
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:127.0.0.1:8384 userid@servername and didn’t edit any api tokens inside of any config.xml.
systemctl status syncthing@userid reports gui listening on 127.0.0.1:8384.
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.
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).
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.