syncthing /config directory permissions in docker container

Support
1

Hello, I’m running a docker instance of syncthing as a non privileged user.

I also have a duplicati container that I use to backup the configuration of all my other containers.

The problem I’m running into is it appears syncthing changes the permissions of it’s /config folder whenever the syncthing docker container starts. is there a way to stop this from happening?

Everytime the syncthing container starts it’s wiping out the permissions I need for duplicati to back up it’s configuration file.

ex:

chmod 770 /mnt/user/appdata/syncthing-inittab

ls -al /mnt/user/appdata/syncthing-inittab

drwxrwx— 1 inittab users 156 Feb 3 07:13 syncthing-inittab/

restart container

ls -al /mnt/user/appdata/syncthing-inittab

drwx------ 1 inittab users 156 Feb 3 07:13 syncthing-inittab/

I’ve also tried to add specific acl’s to allow duplicati to backup this directory but the same thing happens on container restart, the permissions are removed.

2

Currently, no.

3

Any suggestions for how to work around this?

4

Ensure Duplicati is running as the user that owns the directory, or as a more privileged user?

5

This would either involve running duplicati as root which I would prefer not to do, or having multiple duplicati instances for each syncthing container.

Is this something that I should put in as a feature request? I really rather not have my duplicati instance run as root just for the syncthing containers.

6

You certainly can. I was curious about when this behaviour was introduced and slightly surprised to see it present in the first commit in the repo from 13 years ago. Which is to say, it doesn’t seem to be something that comes up very often as this is the first complaint about it I can recall. :slight_smile: It predates not only our docker image but docker as a concept entirely.

7

Not necessarily. I do something similar and I don’t run either as root.

The Syncthing and Duplicati containers support the linuxserver convention of allowing the user to specify PUID/PGID. Duplicati’s container is a linuxserver container. Syncthing has an official container and there’s also a linuxserver container - both of these support the convention.

If you specify the same PUID/PGID for both Syncthing and Duplicati, you won’t have the issue you’re running into.

I’ve done this by creating a User/Group on the host that is specifically dedicated to this purpose.

In practice, I have one user/group that I try to use for all containers and another that I use for the specific, small number of containers that need to see across boundaries. In my case, this is Syncthing, Duplicati, File Browser.

You just need to make sure that you’ve also granted this higher privileged container user the correct access rights to the folders you want synced and backed up. I grant that full rights to those folders but use docker read only mappings for Duplicati.

I don’t think you should log a bug against Syncthing for the behavior you identified. it’s doing what linuxserver containers typically do. The startup sequence for these containers is typically something like:

  • read the PUID/PGID if set in the environment (cmd line or compose)
  • create the specified use in the container or change the UID/GID or an existing
  • set ownership of key paths to the specified user (such as config)
  • drop privileges by running the actual process (such as syncthing) as the specified user

It’s an important pattern because - it guarantees that the admin can specify the user that the container’s key process(es) should run under and allows that to be a non-root user.

One outcome of this is that it blows away whatever custom permissions you’ve put on a file or folder that the container has every right to treat as it’s own, internal file. So rather than request that the container owner stop setting the container’s config file to the correct permission, you should make sure that whatever other processes, such as Duplicati, you want to read this private Syncthing file are able to actually to actually do so.

Hope this helps!

1 Like
8

Unless I’m misunderstanding something basic here this doesn’t really solve the issue of seperate permissions, for example, I have two different syncthing containers, one for me, one for my wife, these containers use puid to run as our specific users.

If I had to use the same PUID between both syncthing containers and duplicati, this means I could read her files, and she could read my files on the system. (granted this isn’t a big issue between me and my wife, but it would be if i wanted to run seperate syncthing instances for friends, etc).

I will state that the syncthing container is the only container i’m seeing this issue with out of all the docker containers I run on the system, syncthing is the only one overwriting the acl permissions on the appdata folder.

I also talked to the linuxserver folks before coming over here and they stated that nothing in their specific container would be changing the permissions on the /config folder

9

There’s a lot here.

I appreciate that you’re trying to preserve the privacy of other users including your wife. You may have reasons for doing what you’re doing with multiple containers, but it’s not a privacy choice. The fact that you can set these containers up in the first place suggests that you are in an administrative role and that you have the ability to grant processes the rights to see this data. If you really wanted to see it yourself, you’d just sudo. I’m just pointing this out because performative privacy isn’t actual privacy. The multi-container approach you’re using is creating complexity but isn’t really changing the fundamental privacy calculus of your system.

When your wife or your friends put content on a system that you administer, they are accepting that the human administrator of the service can see their content if they really want to. You can sudo on the system and you can also even access their backups. This may still net out for you such that yo want to run multiple containers each with a different privacy model. But you may find that if it is truly performative, then you’d be better off just deploying one instance of Duplicati and one of Syncthing.

If you really want to run multiple of each, though, have you tried running them as your wife’s account, your account, etc? In other words, if the model you want is one Duplicati and one Syncthing each, for both you and your wife, then have you tried deploying the pair such that they use your user/group as the PUID/PGID for your pair and her user/group for her pair?

Regarding chown in linuxserver containers. I’m not sure who you spoke to at linuxserver or what they told you. This is a pretty good, though high level, primer on how containers start up:

Note the comment “s6 iterates through our init scripts setting up users, configuring folders and permissions, and anything else the application we’re running needs”.

This is a reference to the work done by the linuxserver base image in fix-attrs.d. That’s a core component of the s6 system and it does what you’re seeing.

You shouldn’t trust me on this. You can go to Google or your favorite AI and type this:

”When starting a linuxserver container, is it typical for the container’s config folder to be chowned to the user-specified PUID/PGID?” Please do this. I think it will confirm what I’ve said.

I’m very much just trying to help.

1 Like