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?
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?
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
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 untickIgnore 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.