Quando eu construo esta imagem com docker build -t myname/symfony_apps:latest . e execute 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 com a qual verifiquei ls -a e as permissões estão bem. e quando executo o chmod do bash do contêiner , os problemas de permissão do apache desapareceram e o aplicativo funciona bem
Situacao
Executando comandos chmod 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á em execução
Alguma ideia, estou perdendo alguma coisa, talvez devesse 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/html e permissões de configuração (em um RUN comando):
Este problema é provavelmente o resultado de um VOLUME definição dentro do Dockerfile upstream. Quando um volume é definido no Dockerfile, você pode adicionar arquivos com um COPY ou ADD comando diretamente na imagem. No entanto, a RUN linha vai:
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 este RUN comando, você 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 mudanças 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 tê-los permanecer)
Essas alterações não incluirão o conteúdo de volume anônimo porque não existem dentro do sistema de arquivos de contêiner temporário, os volumes são separados
Por causa desse comportamento, você tem as opções para:
você pode copiar seus arquivos para um diretório diferente e alterar as permissões lá
você pode corrigir as permissões em seu host para que elas sejam copiadas diretamente com essas permissões
você pode remover o volume de sua imagem, Obter a imagem upstream para remover sua definição de volume ou reconstruir sua própria cópia da imagem upstream sem a definição de volume e basear suas imagens nisso
Observe que dentro das imagens php atuais, parece que o volume foi removido, o que significa que efetivamente temos a opção 3.
Quando eu substituo esse arquivo executável por meio de volumes docker-compose, o execute a permissão é simplesmente como uma reversão-tecnicamente anulada à permissão de arquivo original.
A correção para o modo dev é simplesmente para chmod a+x yourfile do host, que será herdado na montagem de volume de composição.
Estou vendo um espaço extra em seu último comando (estou no meu telefone, então não posso ter certeza). Como o problema de permissão parece ser com o diretório de log, altere a última linha para: ``
Executar chmod-R 777 / var / www / html / app / cache / var / www / html / app / logs
Não consigo reproduzir o seu problema. Se eu usar seu dockerfile e configurar alguns arquivos fictícios localmente, as permissões estão corretas e tudo funciona. Posso inicializar um contêiner e acessar o conteúdo por meio de um navegador da web. Você pode atualizar sua pergunta para incluir mensagens de erro específicas? Você tem certeza de sua configuração Apache ('apache2.conf`) não está causando um problema? Os erros desaparecem se você não instalar ’ apache2.conf?
