I hope this hasn’t been raised already. Would it be possible to make syncthing a little more friendly for running as a single/global background process/demon on *nix platforms? I was thinking of the following small(ish) extra features - with the most important first:
Ability to set the location of the index directory, either on the command line or in the config file. I have currently configured syncthing to keep its home dir in /etc/syncthing, but this includes /etc/syncthing/index, and /etc is not really a suitable location for constantly changing files. If there would be a way to tell syncthing to look for the index dir somewhere else, for example under /var/spool/syncthing - that would be more in line with what normal demons do on *nix.
Slightly less important - an option on the command line or in the config file for the location of the log file. At the moment this doesn’t seem possible - so it would be nice to be able to keep the syncthing logs in /var/log/syncthing/ for example - when it is run as a single, global instance.
This is less important than the above, but an option to keep syncthing quiet on startup (for starting from scripts) would be useful. I notice the Windows version seems to have a “-no-cli” option - or similar. I can’t seem to find one on Linux.
If some of the above are already possible, I couldn’t find them using “–help” or the documentation - so maybe that needs some work instead?
Syncthing is essentially single-user and should be run as a normal user or specific service account. As such, the usual setup puts all files in /home/someuser, even if that user is syncthing. It could of course be /var/lib/syncthing or something if you prefer.
I’d recommend against /etc as the config and so on are also variable data, as Syncthing should be able to write to them to handle config changes from the GUI.
You’d typically send the output to syslog in this case and then handle it like any other service. The runit example script does this and I’ll bet the systemd stuff puts the output in some weird binary place only accessible with a proprietary tool, as is custom there.
The info level messages are actually useful though, and usually after the fact (so turning them on when you need them is too late). Given that you log to syslog or a file, does it matter if there is some output during normal operations?
Thanks for the quick reply Jakob. I guess, with the way syncthing works, it could be thought of as similar to Postgresql, where the data folder contains the settings for that dataset as well. Somewhere under /var (or some distributions use /srv) seems like a reasonable idea - as it might be a bit pedantic, but /home should really be reserved for data of real/human users logging onto a system - and not the data of background services/demons.
It’s important to note that Syncthing is a user-level application, which synchronizes a user’s files. It should not be given access to system files, nor run with root permissions.
By default, Syncthing runs without a GUI password. In this setup, anyone (on the local machine) can connect to Syncthing and command it to read/write any file it has permission to access. Setting a GUI password mitigates this in theory, but it still puts Syncthing as the sole thing standing between an attacker and root access, which is not a nice position to be in!
You’ll note that the systemd scripts (I’m not familiar with the others, although I would assume this applies for them too) are set up to run Syncthing under a particular user: either starting on boot, or when the user logs in.
That said, you can pass -home to syncthing.exe, to tell it where to store its data and configuration.
This is very important, my how-to (albeit, slightly outdated) gives you step by step instructions on how to get it running as a certain user as a service and how to use journalctl to view output.
Thanks Antony and Michael. You may note that I didn’t mention anywhere in my original post about running syncthing as root. I was only looking for ways to integrate it better as a system demon - which seems perfectly feasible using Jakob’s suggestions. When running on a headless server, being able to start it up as a demon is a necessity. There are many, many examples of demons in the *nix world running as their own user - including exim, dovecot, postgresql and even asterisk. Thus running syncthing as a demon under its own user would be perfectly within the norm. Also, by using “syncthing -nobrowser” in the startup script - access from other local users should be removed - unless there is some other way around it.
Regarding journalctl, I believe it is part of systemd - which I don’t use on my system. I’m happy to redirect the output to a syncthing.log plain text log though.
As long as the GUI has a password set and the config directory is not readable by other users you should be fine. Syncthing tries to set the permissions there appropriately, iirc.
Thank you Jakob. Just for reference purposes, would setting “gui enabled=false” in the config file remove completely the issue of local users obtaining unauthorised access because of a lack of password?
