I have Sncthing set up on a banana pi running Debian. This is a headless setup so I’m trying to connect to the gui by setting up an ssh tunnel like so:
ssh -L 8080:127.0.0.1:8384 user@bananapi
the ssh connection is successful, however when i try to open 127.0.0.1:8080 in a browser the page doesn’t load and the ssh session throws the following error:
channel 3: open failed: connect failed: Connection refused
Every once in a while (say 1 out of every 100 connection attempt) the gui does open up and the error is not shown, however i don’t see that connected to any action i take.
I am seeing the same issue on a different machine running Ubuntu 16.04 headless. Another Ubuntu machine as well as another banana pi running the same version of Debian and Syncthing almost always work without a hitch.
I should also mention that on the Ubuntu machine with the issue another ssh port tunnel works flawlessly (for Duplicati).
I checked that sshd_config has AllowTcpForwarding yes in both host machines.
Any pointers on where to start looking for the source of the problem would be super appreciated.
I made an interesting discovery: after connecting with the ssh tunnel if i run systemctl --user status syncthing and then immediately after that sudo systemctl status syncthing and then i try reloading the gui, it does load without issues.
I’m not sure why this is yet.
I set up two brand new machines on DO with Ubuntu 16.04, installed syncthing on both and i see the same: first the error, then after the double status check the gui loads.
As these are brand new machines, the ssh settings are default except for AllowUser and AllowTcpForwarding directives.
Come on guys, systemd may be a craken that tries to do everything by itself and may have numerous other flaws, but it’s basic service management isn’t that bad
In one of your posts you wrote about both using --user and not with systemctl. There are two fundamentally different types of systemd services: System services and user services (with --user). The difference is simple: System services run on boot and are administered by root, user services run at login and can be administered without root privileges. So I assume you set up systemd user services while you actually wanted system services.
My guess would be that you are using a low power device like a Raspberry Pi or similar. I’ve got some experience trying to use those as sync servers, and it works more or less okay, depending on the amount of files and the overall space uses. But those slow devices need several minutes (1-35, depending on how slow they are and how resource intensive the stuff you want to sync is).
I dropped the first generation Pis, because they were really slow with their single core, but also because Raspbian had an unfortunate bug back then that regularly made the mount point of USB devices break.
My advice would be to use something with a minimum of two cores and AES-NI if it’s an Intel chip or the comparable AMD/ARM feature. The Zbox C3XX series works well for me with ~20 repos, >1TB total synced files and a healthy mix between really big (1080p+4k videos) and really small files (config + text files).
@imsodin`s answer from above seems to be correct.
Regardless, I’m seeing the same issue on both a Banana Pi which is dual core with 1 gig of ram and a 3 core 8gig VM running on an AMD opteron based host machine. What’s more I have a second Banana Pi set up, same exact model, same version of Debian and that machine doesn’t have the same issue.
That said, the user vs system service suggestion seems to be the source of this indeed.