Tuve un problema similar al compartir un punto de montaje nfs como un volumen usando docker-compose. Pude resolver el problema con:
docker-compose up --force-recreate
Aunque haya encontrado el problema, esto puede ayudar a otra persona.
Un permiso denegado dentro de un contenedor para un directorio compartido podría deberse al hecho de que este directorio compartido está almacenado en un dispositivo. Por defecto, los contenedores no pueden acceder a ningún dispositivo. Agregando la opción $docker run --privileged permite que el contenedor acceda a todos dispositivos y realiza llamadas al Kernel. Esto no se considera seguro.
Una forma más limpia de compartir dispositivos es usar la opción docker run --device=/dev/sdb (si /dev/sdb es el dispositivo que desea compartir).
Desde la página del manual:
--device=[] Add a host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm) --privileged=true|false Give extended privileges to this container. The default is false. By default, Docker containers are “unprivileged” (=false) and cannot, for example, run a Docker daemon inside the Docker container. This is because by default a container is not allowed to access any devices. A “privileged” container is given access to all devices. When the operator executes docker run --privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor to allow the container nearly all the same access to the host as processes running outside of a container on the host.
Recibí la respuesta de un comentario en:¿Por qué el contenedor de la ventana acoplable solicita Permiso denegado?
man docker-run da la respuesta correcta:
Los sistemas de etiquetado como SELinux requieren que se coloquen las etiquetas adecuadas en el contenido del volumen montado en un contenedor. Sin una etiqueta, el sistema de seguridad podría evitar que los procesos que se ejecutan dentro del contenedor utilicen el contenido. De forma predeterminada, Docker no cambia las etiquetas establecidas por el sistema operativo.
Para cambiar una etiqueta en el contexto del contenedor, puede agregar cualquiera de los dos sufijos :z o :Z al montaje del volumen. Estos sufijos le indican a Docker que vuelva a etiquetar los objetos de archivo en los volúmenes compartidos. La opción z le dice a Docker que dos contenedores comparten el contenido del volumen. Como resultado, Docker etiqueta el contenido con una etiqueta de contenido compartido. Las etiquetas de volumen compartido permiten que todos los contenedores lean/escriban contenido. La opción Z le dice a Docker que etiquete el contenido con una etiqueta privada no compartida. Solo el contenedor actual puede usar un volumen privado.
Por ejemplo:
docker run -it --name oracle_install -v /root/database:/tmp/install/database:z ...
Otro motivo es una discrepancia con el UID/GID. Esto a menudo se muestra como la posibilidad de modificar un montaje como root pero no como el usuario de contenedores
Puede configurar el UID, por lo que para un contenedor de ubuntu que se ejecuta como ubuntu, es posible que deba agregar :uid=1000 (consultar con id -u ) o configure el UID localmente según su caso de uso.
uid=valor y gid=valor
Establezca el propietario y el grupo de archivos en el sistema de archivos (predeterminado:uid=gid=0)
Hay un buen blog sobre esto aquí con este ejemplo de tmpfs
docker run \
--rm \
--read-only \
--tmpfs=/var/run/prosody:uid=100 \
-it learning/tmpfs
http://www.dendeer.com/post/docker-tmpfs/