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
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!
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…
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…
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.
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?
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