directory - totales - permisos terminal ubuntu

Permiso denegado al acceder al directorio del host en la ventana acoplable (9)

ADVERTENCIA: Esta solución tiene riesgos de seguridad.

Intenta ejecutar el contenedor como privilegiado:

sudo docker run --privileged=true -i -v /data1/Downloads:/Downloads ubuntu bash

Otra opción (que no he probado) sería crear un contenedor privilegiado y luego crear contenedores no privilegiados dentro de él.

En resumen: estoy intentando montar un directorio de host en Docker, pero luego no puedo acceder a él desde dentro del contenedor, incluso si los permisos de acceso se ven bien.

Los detalles:

estoy haciendo

sudo docker run -i -v /data1/Downloads:/Downloads ubuntu bash

y entonces

ls -al

Me da:

total 8892 drwxr-xr-x. 23 root root 4096 Jun 18 14:34 . drwxr-xr-x. 23 root root 4096 Jun 18 14:34 .. -rwxr-xr-x. 1 root root 0 Jun 18 14:34 .dockerenv -rwx------. 1 root root 9014486 Jun 17 22:09 .dockerinit drwxrwxr-x. 18 1000 1000 12288 Jun 16 11:40 Downloads drwxr-xr-x. 2 root root 4096 Jan 29 18:10 bin drwxr-xr-x. 2 root root 4096 Apr 19 2012 boot drwxr-xr-x. 4 root root 340 Jun 18 14:34 dev drwxr-xr-x. 56 root root 4096 Jun 18 14:34 etc drwxr-xr-x. 2 root root 4096 Apr 19 2012 home

y muchas más líneas como esa (creo que esta es la parte relevante).

Si lo hago

cd /Downloads ls

el resultado es

ls: cannot open directory .: Permission denied

El anfitrión es Fedora 20, con Docker 1.0.0 y go1.2.2.

¿Alguna idea de lo que va mal?

Desde access.redhat.com:Sharing_Data_Across_Containers :

La configuración del volumen del host no es portátil, ya que depende del host y puede que no funcione en ninguna otra máquina. Por este motivo, no hay un archivo de Docker equivalente para montar directorios de host en el contenedor. Además, tenga en cuenta que el sistema host no tiene conocimiento de la política de SELinux del contenedor. Por lo tanto, si se aplica la política SELinux, el directorio del host montado no se puede escribir en el contenedor, independientemente de la configuración de rw. Actualmente, puede solucionar este problema asignando el tipo de política SELinux adecuado al directorio de host ":
chcon -Rt svirt_sandbox_file_t host_dir

Donde host_dir es una ruta al directorio en el sistema host que está montado en el contenedor.

Parece ser solo una solución, pero lo intenté y funciona

Es un problema de selinux.

Se puede emitir temporalmente

su -c "setenforce 0"

en el host para acceder o agregar una regla selinux ejecutando

chcon -Rt svirt_sandbox_file_t /path/to/volume

Resolví ese problema usando un contenedor de datos, esto también tiene la ventaja de aislar los datos de la capa de aplicación. Podrías ejecutarlo así:

docker run --volumes-from=<container-data-name> ubuntu

Este tutorial proporciona una buena explicación sobre el uso de contenedores de datos.

Trate de docker volume create .

mkdir -p /data1/Downloads docker volume create --driver local --name hello --opt type=none --opt device=/data1/Downloads --opt o=uid=root,gid=root --opt o=bind docker run -i -v hello:/Downloads ubuntu bash

Eche un vistazo al documento https://docs.docker.com/engine/reference/commandline/volume_create/

Tuve un problema similar, el mío se debió a una falta de coincidencia entre el UID del host y el UID del usuario del contenedor. La solución fue pasar el UID del usuario como un argumento a la compilación de la ventana acoplable y crear el usuario del contenedor con el mismo UID.

En el DockerFile:

ARG UID=1000 ENV USER="ubuntu" RUN useradd -u $UID -ms /bin/bash $USER

En el paso de compilación:

docker build <path/to/Dockerfile> -t <tag/name> --build-arg UID=$UID

Después de eso, ejecutar el contenedor y los comandos según el OP me dio el resultado esperado.

Vea esta entrada del blog de Project Atomic sobre Voumes y SELinux para la historia completa.

Específicamente:

Esto se hizo más fácil recientemente, ya que Docker finalmente fusionó un parche que aparecerá en docker-1.7 (Hemos estado cargando el parche en docker-1.6 en RHEL, CentOS y Fedora).
Este parche agrega soporte para "z" y "Z" como opciones en los montajes de volumen (-v).
Por ejemplo:
docker run -v /var/db:/var/db:z rhel7 /bin/sh
Hará automáticamente el chcon -Rt svirt_sandbox_file_t /var/db descrito en la página del manual.
Aún mejor, puedes usar Z.
docker run -v /var/db:/var/db:Z rhel7 /bin/sh
Esto etiquetará el contenido dentro del contenedor con la etiqueta MCS exacta con la que se ejecutará el contenedor, básicamente ejecuta chcon -Rt svirt_sandbox_file_t -l s0:c1,c2 /var/db donde s0:c1,c2 difiere para cada contenedor.

chcon -Rt svirt_sandbox_file_t /path/to/volume que chcon -Rt svirt_sandbox_file_t /path/to/volume funciona y no tiene que ejecutarse como un contenedor privilegiado.

Esto está en

Docker versión 0.11.1-dev, compilación 02d20af / 0.11.1
Centos7 como host y contenedor con selinux habilitado.

sudo -s hizo el truco para mí en MAC