Permission denied while trying to bind mount a persistent volume....

[Shadow]

I'm trying to simply deploy a container while using the -v flags to mount persistent data from my Synology 'Docker' share into the container. I get below error:

Shadow@NAS3:/volume1/docker$ sudo docker run --name nginx-php --hostname nginx-php --restart unless-stopped --network physical _network_noproxy --ip 192.168.1.210 --dns 192.168.1.194 -v /volume1/docker/nginx-php/etc:/etc -v /volume1/docker/nginx-php/sha re:/var/www/html -d trafex/alpine-nginx-php7
7327f229afa438bdc2875cf8acc7b2a64885d3c4e3c5f00b360abcc614249133

docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "chdi r to cwd (\"/var/www/html\") set in config.json failed: permission denied": unknown.

Running other containers on this exact same way goes without problems..

Shadow@NAS3:/volume1/docker/nginx-php$ ls -l
total 0
drwxrwxrwx+ 1 root root 710 Nov 9 12:45 etc
drwxrwxrwx+ 1 root root 44 Nov 9 12:45 share
drwxrwxrwx+ 1 root root 20 Nov 9 12:45 share2
Shadow@NAS3:/volume1/docker/nginx-php$

Even this doesn't work... Anyone has any tips for me...?

 

[one-eyed-king]

Whenever it doesn't make sense that a bind-mount doesn't work, usualy ACL, selinux or apparmor is responsible Afaik we only have ACLs on the Syno.

I am by no means an expert when it commes to Syno ACLs. At least I figured out how to delete them for a specific folder (and even subfolders and files). Stop the affected container and execute this snippet in a root shell to delete ACL's for the folder and all the files and subfolders in it:

find /volume1/docker/nginx-php -exec echo "{}:" \; -exec synoacltool -del {} \;

Verify if the mount works in nginx. Once they do, you can re-apply the ACLs to that folder.

 

[Shadow]

find /volume1/docker/nginx-php -exec echo "{}:" \; -exec synoacltool -del {} \;

I ran this as root. But it still didn't work. But then after that I gave EVERYONE R+W access to the /volume1/docker/nginx-php folder, it worked...

I really don't like using 'Everyone', especially on Windows ......

(I do lockdown permissions on the parent folder of the share ofcourse ( /volume1/docker/ ))

 

[one-eyed-king]

Sometimes strange problems require esotheric solutions

I would remove the acl's again and check what UID/GID ownership the container requires for its bind-mount.

 

[Shadow]

Another solution I found is to use the -PUID and -GUID environment vars in the Docker container. So I first created a 'service' account in my LDAP , gave it the least level of permissions it needed. Then with an LDAP browswer I searched the PUID and GUID value's for that account and entered that in the Docker run container. The Docker container should than use that account to access the file system of the host specified on the volume bound.

Tonight I can show you screenshots, as I'm 'at' work at the moment.

 

[one-eyed-king]

Limiting access to UID/GID of the bind-mount "volume" is of course the prefered approach.

Though this is only possible, if:
- if you are able identify the UID/GID inside the container and make it the owner of the folder on the host
- the image implements support for user/group mapping using environment vars in their entrypoint script (e.g. all Linuxserver images do)..
- the Dockerfile of the image uses the USER directive, adding -u UID:GID will override the uid/gid for the user of the first USER directive.