Uso el siguiente comando para ejecutar un contenedor docker y asignar un directorio desde el host ( /root/database ) al contenedor ( /tmp/install/database ):
# docker run -it --name oracle_install -v /root/database:/tmp/install/database bofm/oracle12c:preinstall bash Pero en el contenedor, encuentro que no puedo usar ls para listar contenidos en /tmp/install/database/ aunque soy root y tengo todos los privilegios:
[root@77eb235aceac /]# cd /tmp/install/database/ [root@77eb235aceac database]# ls ls: cannot open directory .: Permission denied [root@77eb235aceac database]# id uid=0(root) gid=0(root) groups=0(root) [root@77eb235aceac database]# cd .. [root@77eb235aceac install]# ls -alt ...... drwxr-xr-x. 7 root root 4096 Jul 7 2014 database Compruebo /root/database en host, y todo parece estar bien:
[root@localhost ~]# ls -lt ...... drwxr-xr-x. 7 root root 4096 Jul 7 2014 database¿Por qué el contenedor docker indica "Permiso denegado"?
Actualizar :
La causa principal está relacionada con SELinux . En realidad, me encontré con un problema similar el año pasado.
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. Agregar la opción $docker run --privileged permite que el contenedor acceda a todos los dispositivos y realice 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 (eg --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 compartidas 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 ...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-recreateAunque haya encontrado el problema, esto puede ayudar a otra persona.