Si encuentras algún detalle que no entiendes puedes comentarlo y te ayudaremos lo más rápido posible.
Solución:
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 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).
De 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.
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.
Te mostramos comentarios y valoraciones
Si crees que te ha resultado de utilidad este artículo, sería de mucha ayuda si lo compartes con otros desarrolladores de esta forma nos ayudas a extender nuestro contenido.