Permission issue with docker (stat: permission denied although it's possible)

I moved Syncthing from Ubuntu to Docker on Ubuntu and somehow can’t get it to work:

Error shown in Web-UI: 2019-12-13 08:07:05: Error on folder “FOLDER1” (xxxxx-yyyyy): stat /datapool1/backup/PATH/FOLDER: permission denied

Error in syncthing log:

WARNING: Loading ignores: open /datapool1/backup/PATH/FOLDER/.stignore: permission denied
WARNING: Failed to create folder marker: stat /datapool1/backup/PATH/FOLDER/.stfolder: permission denied

But I can stat that folder without Problems, when I exec into the container as user syncthing: File: /datapool1/backup/PATH/FOLDER Size: 23 Blocks: 17 IO Block: 1536 directory Device: 2ch/44d Inode: 286875 Links: 22 Access: (0770/drwxrwx—) Uid: ( 1004/USERA) Gid: ( 1008/USERA)

I can also ls that directory and the .stfolder within, and cat the .stignore

Fun fact, /datapool1/backup/PATH/FOLDER2 is working without a problem. Permissions are the same - and both are working fine using sycthing without docker

Edit: When the files and folder are owned by the syncthing user I don’t have any problems. I do have problems, when the permissions are granted via group. But as I said, I have full access to the files in the container!

I believe there has been exact same question like a week ago. Suggest you try searching for permission denied and see if you can find it.

That might have been really the exact same question, by the same OP but on Github if I remember correctly :wink:

The advice still applies, as I do remember a few previous support requests around docker and permissions.

Thanks for your answers guys, but I can promise, I googled and searched this forum a lot and checked most results.

But nothing besides giving syncthing full ownership of all shares folders works… :frowning: And I just don’t get it. Execing as the user running syncthing (1009: syncthing) I can rm, mkdir and also stat the .stfolder with no worries. But syncthing just says stat /path/.stfolder: permission denied

Any ideas what to do to get more grip on that problem? Any chance of deeper debugging? Although I have no clue in which direction that could go… container runs 3 processes:

   15     1 syncthin SN    186m   1%   1   0% /bin/syncthing -home /var/syncthing/config
    1     0 syncthin S     117m   1%   0   0% /bin/syncthing -home /var/syncthing/config
   64     0 syncthin S     1656   0%   1   0% sh

I can stat the folder from sh without a problem being the same user as the syncthing process…

Don’t forget you need execute permission for things like listing directory content, so rw is not enough.

Also, make sure that parent directory where .stfolder is being created has rwx for the user running the process.

Lastly, I think you might hit other issues by not handing ownership to syncthing. I don’t have exact failure scenario in mind, but my spider senses say it might not work.

Docker et al, support user remapping, so I don’t see why you insist on syncthing not owning the files.

The user has permisson of the parent folder of 7: rwx, but only via it’s group. What I don’t understand is, why this setting works perfectly on the host-system where I still have the productive syncthing running in the same constellation.

I am using permission by groups as it is easier to add syncthing to a lot of groups with access rights to the several files locations than having syncthing beeing the owner of all those locations, which are managed by different programs.

I am open to workarounds. But would that work for different owners on the original filesystem as I’d reckon I had to map the different owners to the same user in the container running syncthing?

The suggested user re-mappings should work in theory.

I guess it could be some sort of seccomp or apparmor stuff, so you should check the security/system logs for clues.

Also, exec into the container doesn’t really have the same behaviour as the launching process. I guess you can verify that by running the container with sleep 9000, execing in, and then launching syncthing.

You can also run strace, but I suspect you’ll just get permission denied from the kernel with no reason why. The error you are seeing we are nto inventing ourselves, we just return what the operating system gave us.

Holy moly! That was the key! Exactly as you described, using sleep and running the command as the execed user manually worked as wanted! So I tried to get the magic of entrypoint.sh

#!/bin/sh

set -eu

chown "${PUID}:${PGID}" "${HOME}" \
  && exec su-exec "${PUID}:${PGID}" \
     env HOME="$HOME" "$@"

I overwrote the entrypoint by

USER syncthing
ENTRYPOINT ["/bin/syncthing", "-home", "/var/syncthing/config"]

and at the first sight everything seems to work as expected. I don’t have to chown the home directory since that is mounted anyways.

I guess the entrypoint.sh way is meant to be working in a more general way? But still, it seems to stop group permissions to work. Have you tried to make it work without the entrypoint.sh? Would it make sense that I try and provide a possible solution as PR?

I don’t really see why the entrypoint would cause this, but if you can figure it out, PRs are more than welcome.

Did you set PGID to your desired group ID?

Well, I guess it could be some issue with the used su-exec?

I will try and see. I think my solution isn’t generic enough as the user is hard coded. For a general solution I would also have to use some entrypoint.sh, but maybe just using another command.

Yes, I did - and in the exe-shell everything is working as supposed


Nevertheless - thanks a lot for your answers and the hint about the difference executed shell and the run command from dockerfile, that was the key for me. I will move my production completely to docker now and check if everything is stable and then figure out whether I could find a way worth a PR

cheers and keep up the good work!

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.