Linux File Ownership

[yknivag (Gavin)]

Apologies if this is covered elsewhere, I couldn’t find anything searching (save a thread from 2014), but I may not have searched for the correct terms.

I am using Syncthing in perhaps a slightly unusual arrangement. My aim was sync between desktop and laptop but it is rare that both are switched on at the same time, so I an running Syncthing on a Pi using Docker and have a three-way share. The Pi is always on and so files successfully sync between all three devices.

In the docker-compose.yml file I set the PUID/PGID as 1000/100 (pi:users)

The sync folder is:

drwxrwsr-x user1:users /home/user1/sync (mapped appropriately into the container)

When files are created there by Syncthing they are created as owned by pi:users

This is, I suppose, to be expected as that is the user that docker is running Syncthing as.

Ideally I’d like these files to be owned by user1:users instead. In config.xml I see there is a setting for copyOwnershipFromParent but I can’t find a way to set this in the web interface. I tied stopping the container, changing the setting directly in the xml file and restarting the container, but nothing changes and when I look at the config.xml file again it has been changed back.

I don’t want to run the container as user1 as there is also user2 (configured exactly as above) and that would mean running two separate containers.

Is there a way of setting Syncthing to use specific ownership when saving files?

If not is it possible for the files it saves to be saved as group writable?

Thank you.

[wweich]

You can set that option in the advanced settings.

[odin (Herbert Snorrason)]

@yknivag

Is there a way of setting Syncthing to use specific ownership when saving files?

This involves chown, and is therefore a privileged operation. In short, the only portable way to do it is to be root.

[yknivag (Gavin)]

Hi,

Thanks for the reply. I have set it to true and now the files don’t sync to the Pi, because the user pi that Synchthing is running as doesn’t have permission to chown to user1.

After some further thought that isn’t going to be possible as I’m not sure I’d want to run Syncthing as root.

That just leaves the option of setting the files to be group writeable. This should be possible by setting UMASK=002 in the environment section of the docker-compose.yml file.

However, whilst I can make Syncthing run with a process umask of 002, that isn’t respected when the files are written and they are written as rw-r--r-- rather than the desired rw-rw-r--.

Is there a way of setting the desired permissions from within Syncthing?

[imsodin (Simon)]

@yknivag

After some further thought that isn’t going to be possible as I’m not sure I’d want to run Syncthing as root.

There’s also the CAP_CHOWN which grants an unprivileged user the ability to chown.

@yknivag

However, whilst I can make Syncthing run with a process umask of 002, that isn’t respected when the files are written and they are written as rw-r--r-- rather than the desired rw-rw-r--.

Is there a way of setting the desired permissions from within Syncthing?

Syncthing uses 0666 if permissions are ignored. So something in your system is restricting the permissions further or the UMASK env var is dropped/not propagated somewhere along the way.

[odin (Herbert Snorrason)]

@imsodin

There’s also the CAP_CHOWN which grants an unprivileged user the ability to chown.

True, but if the permissions aren’t set up such that the Syncthing user can write to the files being synced, you’ll run into trouble further down that road.

[yknivag (Gavin)]

@imsodin

There’s also the CAP_CHOWN which grants an unprivileged user the ability to chown.

This is very interesting. A quick search of this forum seems to suggest that the way forward here is to provide the Syncthing binary with the CAP_CHOWN capability. What isn’t clear is how to do this when that binary is running inside a docker container.

Is it possible?

@odin

True, but if the permissions aren’t set up such that the Syncthing user can write to the files being synced, you’ll run into trouble further down that road.

I can imagine that could cause a whole world of pain, in my particular use case that shouldn’t be a problem as Syncthing is running as a user which belongs to the group which owns it’s target directories, with a UMASK of 002 and those target directories are group writable and have the setguid bit set

@imsodin

Syncthing uses 0666 if permissions are ignored. So something in your system is restricting the permissions further or the UMASK env var is dropped/not propagated somewhere along the way.

I figured that one out last night! I had just come back here to update the thread when I saw your reply.

Rather counter-intuitively I had to untick Ignore Permissions for the umask to be respected. Probably because I was testing by adding files from a Windows machine which wouldn’t have the g+w set.

The combination of this and the CAP_CHOWN seems to be exactly what I am seeking. Just have to figure out how to enable the capability.

[epe (eric poscher)]

This topic shows up in different threads.

What is CAP_CHOWN and how to use it?

Could someone explain how it can be done?

[calmh (Jakob Borg)]

It’s the ability to call chown to change ownership on a file without being root. The only use is with the inherit-parent-dir-owner option in Syncthing.