Estou criando uma imagem do Docker para o meu Symfonyaplicativo e preciso dar permissão ao servidor apache para gravar em cache e pastas 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 crio esta imagem docker build -t myname/symfony_apps:latest .e executo o contêiner com docker run -p 8080:80 myname/symfony_apps:latest. O log do Apache é inundado por erros de permissão negada, a coisa estranha que eu verifiquei ls -ae as permissões estão bem. e quando executo o chmod a partir do bash do contêiner, os problemas de permissão do apache desaparecem e o aplicativo funciona bem

A situação

Executando comandos chmod a partir do dockerfile: as permissões são alteradas, mas o apache ainda reclama da permissão negada. Executando os mesmos comandos chmod com bash dentro do contêiner: as permissões são alteradas e meu aplicativo está sendo executado

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

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

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

COPY . /src

E então mova-o para /var/www/htmle configure as permissões (em um RUNcomando):

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 um problema no GitHub .

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

Mas você pode mudar para usar / bin / bash para corrigir facilmente, observe 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

Tente adicionar:

USER root

Funcionou para mim.

Esse problema provavelmente é o resultado de uma VOLUMEdefinição no Dockerfile upstream. Quando um volume é definido no Dockerfile, você pode adicionar arquivos com um comando COPYou ADDdiretamente na imagem. No entanto, uma RUNlinha irá:

• Crie um contêiner temporário usando a definição de imagem no 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 este RUNcomando, verá suas alterações aplicadas, mas essas alterações foram aplicadas ao volume
• Quando o comando executar for concluído, o docker capturará as alterações no contêiner
  • Essas alterações podem ser vistas com a docker diffse você não excluir os contêineres temporários (você pode executar uma compilação --rm=falsepara que eles permaneçam)
  • Essas mudanças não incluirão o conteúdo do volume anônimo porque elas não existem no 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 upstream para remover a definição de volume ou reconstruir sua própria cópia da imagem upstream sem a definição de volume e basear suas imagens nessa

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

Acabei de fazer um experimento com o seguinte:

FROM alpine

LABEL MAINTAINER="YIMGA YIMGA Salathiel Genèse"
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.

Contudo

Quando substituo esse arquivo executável por volumes de composição de janela de encaixe, a executepermissão é simplesmente como retrocedida - substitui tecnicamente a permissão de arquivo original.

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