Eu uso o seguinte comando para executar um contêiner docker e mapear um diretório do Host (/root/database
) para o container (/tmp/install/database
):
# docker run -it --name Oracle_install -v /root/database:/tmp/install/database bofm/Oracle12c:preinstall bash
Mas no container, eu não consigo usar ls
para listar o conteúdo em /tmp/install/database/
embora eu seja root
e tenha todos os privilégios:
[[email protected] /]# cd /tmp/install/database/
[[email protected] database]# ls
ls: cannot open directory .: Permission denied
[[email protected] database]# id
uid=0(root) gid=0(root) groups=0(root)
[[email protected] database]# cd ..
[[email protected] install]# ls -alt
......
drwxr-xr-x. 7 root root 4096 Jul 7 2014 database
Eu verifico /root/database
no Host, e tudo parece OK:
[[email protected] ~]# ls -lt
......
drwxr-xr-x. 7 root root 4096 Jul 7 2014 database
Por que o contêiner do docker solicita "Permissão negada"?
Atualizar :
A causa raiz está relacionada a SELinux
. Na verdade, eu conheci similar problema ano passado.
Uma permissão negada dentro de um contêiner para um diretório compartilhado pode ser devido ao fato de que esse diretório compartilhado é armazenado em um dispositivo. Por padrão, os contêineres não podem acessar nenhum dispositivo. Adicionar a opção $docker run --privileged
permite que o contêiner acesse all devices e execute chamadas do kernel. Isso não é considerado seguro.
Uma maneira mais limpa de compartilhar o dispositivo é usar a opção docker run --device=/dev/sdb
(se /dev/sdb
for o dispositivo que você deseja compartilhar).
Na página man:
--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.
Eu tive um problema semelhante ao compartilhar um ponto de montagem nfs como um volume usando o docker-compose. Consegui resolver o problema com:
docker-compose up --force-recreate
Mesmo que você tenha encontrado o problema, isso pode ajudar alguém.
Outro motivo é uma incompatibilidade com o UID/GID. Isso geralmente é mostrado como sendo capaz de modificar uma montagem como raiz, mas não como o usuário dos contêineres
Você pode configurar o UID, portanto, para um contêiner ubuntu executando como ubuntu, você pode precisar anexar :uid=1000
(verifique com id -u
) ou definir o UID localmente, dependendo do seu caso de uso.
uid = value e gid = value
Defina o proprietário e o grupo dos arquivos no sistema de arquivos (padrão: uid = gid = 0)
Há um bom blog sobre isso aqui com este exemplo tmpfs
docker run \
--rm \
--read-only \
--tmpfs=/var/run/prosody:uid=100 \
-it learning/tmpfs