Syncing system directories (like /etc) when Syncthing runs as a user service?


(Piotr Dobrogost) #1

I’m curious how do you handle syncing /etc directory when Syncthing runs as a user service (systemctl --user ...)?


(Scott Hansen) #2

You can’t :slight_smile: The process has to have permissions to act on the files it syncs. Not to mention, syncing system directories like /etc and /var is typically going to be a bad idea, as they often contain special file types (like socket files or symlinks) or database files. If you’re going for a backup system, there are a bunch of better suited tools then a one-way Syncthing instance.

Scott

Edit: I should clarify, that you can read any file that the Syncthing user can read, likewise with writes. There are numerous files in /etc/ that are read-only for root, meaning those will not be synced, and none of the files would be able to be overwritten when syncing from another device.


(Pierre-Alain TORET) #3

@firecat4153, as I understand @pwd message, the goal is to sync /etc files to another host in order to back them up from there. In this particular point of view, it will never happen to have modifications on the remote /etc folder and it’s not the backup tool either, just a sync tool (as expected).


(Piotr Dobrogost) #4

How about running extra instance of Syncthing as root for this? This leads to general question – is every user of given computer supposed to run his instance of Syncthing? I guess it would be nice if there would be only one instance of Syncthing handling data of different users. Let’s say each folder could be assigned to specific user.


(Antony Male) #5

Yes each user should run their own syncthing instance. That way each user can have their own configuration, you don’t risk users accidentally being given access to each others’ files through syncthing, etc.

With user services, the service is only started when the user logs on.

As others have said, if you’re looking to back up files, use a backup program.


(Piotr Dobrogost) #6

Should each instance use different device ID for local machine or can all share the same device ID?


(Simon) #7

Same ID is a bad idea for sure, as both instances can run at the same time, in which case another Syncthing instance can’t discern the two. You need different IDs and ports for multiple instances on the same computer. Actually using “Device” is an unfortunate terminology in this context, but I can’t think of anything better (instance would be worse in other ways).


(Antony Male) #8

Indeed, each instance will have its own configuration, which will be accessible only to the user who runs that instance of Syncthing.

Therefore each Syncthing instance will have its own Device ID, and different users can choose to share different files with different people.


(Piotr Dobrogost) #9

Well, the question of how to setup ST for multiple users is actually a FAQ – How do I configure multiple users on a single machine?. There we find the following warning:

Be aware that you might need to configure listening ports such that they do not overlap

but there’s no information on different device ids…


(Antony Male) #10

You do not configure the Device ID yourself. If you have different Syncthing instances where each has its own config (which is the only sensible way to setup multiple Syncthing instances for multiple users), then each instance will get its own Device ID.


(Piotr Dobrogost) #11

Well, I don’t know how but I got into situation in which I had the same device ID in two different configurations on one host (one normal user, one root). I stopped ST system service (which is syncthing@root so configuration is stored in /root/.config/syncthing), deleted /root/.config/syncthing and started service again. This resulted in new device ID so all is well now.

Btw, if anyone needs to manage ST systemd root’s user service then the way to do this is sudo XDG_RUNTIME_DIR="/run/user/0" systemctl --user stop|start|status syncthing. Information obtained from @grawity on #systemd channel. Not setting XDG_RUNTIME_DIR results in Failed to connect to bus: No such file or directory


(Jakob Borg) #12

The device ID is the hash of the public key, which is cert.pem in the config directory. If you clone the config directory, you clone the device ID. This is always a bad idea. :slight_smile:


(Piotr Dobrogost) #13

Sure. I just don’t remember cloning configuration but with my bad memory I never know… :slight_smile:


(Simon) #14

Out of curiosity: Why do you start the root Syncthing instance as a systemd (root) user service and not as a system service?


(Piotr Dobrogost) #15

Well, again I don’t know why but it got installed as a root’s user service :slight_smile: But yes, it does not make much sense so I disabled it and installed system service instead.