chmod não está funcionando corretamente no Docker

5

Estou criando uma imagem do Docker para o meu Symfony app e preciso dar permissão ao servidor do Apache para gravar em pastas de cache e de log

#Dockerfile
FROM php:7-apache

RUN apt-get update \
&& apt-get install -y libicu-dev  freetds-common freetds-bin unixodbc \
&& docker-php-ext-install intl mbstring \
&& a2enmod rewrite

COPY app/php.ini /usr/local/etc/php/
COPY app/apache2.conf /etc/apache2/apache2.conf
COPY ./ /var/www/html

RUN find /var/www/html/ -type d -exec chmod 755 {} \; 
RUN find /var/www/html/ -type f -exec chmod 644 {} \;
RUN chmod -R 777 /var/www/html/app/cache /var/www/html/app/logs

Quando eu criar essa imagem com docker build -t myname/symfony_apps:latest . e executar o contêiner com docker run -p 8080:80 myname/symfony_apps:latest . O log do Apache é inundado por erros de permissão negada, o estranho que eu verifiquei com ls -a e permissões estão bem. e quando eu executo o chmod do bash do container, os problemas de permissão do apache acabam e o aplicativo funciona bem

A situação

A execução de comandos chmod do dockerfile: permissões são alteradas, mas o apache ainda reclama de permissão negada. Executando os mesmos comandos do chmod com o bash dentro do contêiner: as permissões são alteradas e meu aplicativo está em execução

Alguma idéia, estou faltando alguma coisa, talvez eu deva adicionar usuário root em algum lugar no Dockerfile?

    
por storm 22.04.2016 / 15:09

4 respostas

8

Eu tive o mesmo problema e parece que há algum bug no docker ou overlay2 se o conteúdo do diretório é criado em uma camada e suas permissões são alteradas em outra.

Como alternativa, você pode copiar fontes para o diretório temporário:

COPY . /src

Em seguida, mova-o para /var/www/html e configure as permissões (em um comando RUN ):

RUN rm -rf /var/www/html && mv /src /var/www/html &&\
    find /var/www/html/ -type d -exec chmod 755 {} \; &&\
    find /var/www/html/ -type f -exec chmod 644 {} \; &&\
    chmod -R 777 /var/www/html/app/cache /var/www/html/app/logs

Também criei o problema do GitHub .

    
por 05.01.2017 / 23:16
2

O shell padrão do RUN no Docker é / bin / sh e é aqui que as permissões que não estão sendo definidas corretamente têm um problema.

Mas você pode alterar apenas para usar / bin / bash para corrigir facilmente, observar antes e depois da listagem de diretórios

Step 7/9 : RUN /bin/bash -c 'ls -la; chmod +x gitlab-properties-builder.sh; ls -la'
---> Running in dc57ae77aa67

drwxr-xr-x. 3 root root      103 Mar  8 17:56 .
drwxr-xr-x. 1 root root       46 Mar  8 17:57 ..
drwxr-xr-x. 2 root root        6 Mar  7 20:47 config
-rw-r--r--. 1 root root     2340 Mar  7 21:20 gitlab-properties-builder.sh
-rw-r--r--. 5 root root 57325770 Mar  5 14:39 gitlab-scm-collector-2.0.5-SNAPSHOT.jar

drwxr-xr-x. 1 root root       42 Mar  8 17:56 .
drwxr-xr-x. 1 root root       61 Mar  8 17:57 ..
drwxr-xr-x. 2 root root        6 Mar  7 20:47 config
-rwxr-xr-x. 1 root root     2340 Mar  7 21:20 gitlab-properties-builder.sh
-rw-r--r--. 5 root root 57325770 Mar  5 14:39 gitlab-scm-collector-2.0.5-SNAPSHOT.jar
---> 8b5de6e348d3
    
por 08.03.2018 / 19:07
0

Acabei de fazer uma experiência com o seguinte:

FROM alpine

LABEL MAINTAINER="YIMGA YIMGA Salathiel Genèse <> [email protected]"
RUN apk add --no-cache inotify-tools
CMD [ "./script.sh" ]
WORKDIR /opt/app/
COPY src/ /opt/app/
RUN chmod a+x *.sh

E isso funciona muito bem.

No entanto

Quando eu sobrescrevo esse arquivo executável através de volumes que compõem o docker, a permissão execute é simplesmente como reversão - tecnicamente cancelada para a permissão do arquivo original.

A correção para o modo dev é simplesmente para chmod a+x yourfile do host, que será herdada na montagem do volume de composição.

    
por 19.11.2018 / 12:24
0

Esse problema é provavelmente o resultado de uma definição VOLUME dentro do Dockerfile upstream. Quando um volume é definido no Dockerfile, você pode adicionar arquivos com um comando COPY ou ADD diretamente na imagem. No entanto, uma linha RUN irá:

  • Crie um contêiner temporário usando a definição de imagem a partir do ponto atual do dockerfile
    • Esse contêiner temporário terá um volume anônimo montado como você ou uma imagem pai especificada dentro do Dockerfile
    • O volume anônimo será inicializado a partir do conteúdo da imagem
  • Seu comando será executado dentro do contêiner
    • Se você listar o diretório durante esse comando RUN , verá suas alterações aplicadas, mas essas alterações foram aplicadas ao volume
  • Quando o comando de execução é concluído, o docker captura as alterações no contêiner
    • Essas alterações podem ser vistas com um docker diff se você não excluir os contêineres temporários (você pode executar uma compilação com --rm=false para que eles permaneçam)
    • Essas alterações não incluirão o conteúdo do volume anônimo porque elas não existem dentro do sistema de arquivos do contêiner temporário, os volumes são separados

Devido a esse comportamento, você tem as opções para:

  1. você pode copiar seus arquivos para um diretório diferente e alterar as permissões lá
  2. você pode corrigir as permissões em seu host para que elas sejam copiadas diretamente com essas permissões
  3. você pode remover o volume de sua imagem, obter a imagem de envio para remover sua definição de volume ou pode reconstruir sua própria cópia da imagem de envio sem a definição de volume e basear suas imagens fora dela

Note que dentro das imagens atuais do php, parece que o volume foi removido, o que significa que efetivamente temos a opção 3.

    
por 19.11.2018 / 15:10