O erro de permissões era, na realidade, uma confusão de caminhos
Um utilizador do ZimaOS precisava de editar o config.php do Nextcloud para adicionar um endereço da tailnet aos domínios fidedignos. Comandos como chown e usermod não ajudaram, porque a primeira questão não era saber quem era o proprietário do ficheiro, mas sim qual o espaço de nomes do sistema de ficheiros que o comando estava a utilizar.
A discussão chegou a uma resposta bem-sucedida depois de o utilizador inspecionar as montagens do contentor do Nextcloud. O mesmo ficheiro aparecia num caminho no anfitrião ZimaOS e noutro caminho dentro do contentor. Um caminho do contentor introduzido no anfitrião não pode funcionar simplesmente por parecer correto num guia do Nextcloud.
Inspecione a montagem do contentor antes de alterar as permissões
Primeiro, identifique o contentor Nextcloud em execução:
docker ps --format "table {{.Names}}\t{{.Image}}"Em seguida, inspecione as respetivas montagens, substituindo o marcador pelo nome real do contentor:
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'Neste caso, o resultado mostrava:
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlO lado esquerdo é o caminho no anfitrião. O lado direito é o caminho tal como é visto a partir do interior do contentor. Este mapeamento explica por que motivo alterar um diretório não relacionado ou introduzir o caminho do contentor a partir do anfitrião não resolveu o problema.
Utilize o caminho do anfitrião ao editar a partir do ZimaOS
A partir da shell do anfitrião ZimaOS, o utilizador encontrou o ficheiro em:
/DATA/AppData/nextcloud/var/www/html/config/config.phpAssim, o comando de edição correspondente no anfitrião é:
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpAntes de editar, a discussão recomendava verificar tanto o ficheiro como o respetivo diretório-pai:
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configO modo observado do ficheiro era 640 e o proprietário era www-data:www-data. Essa informação é importante, mas o bloqueio final continuava a ser o contexto do caminho. A resposta aconselhava explicitamente a não aplicar alterações aleatórias de propriedade antes de localizar a origem real da montagem vinculada.
Utilize o caminho do contentor apenas depois de entrar no contentor
A alternativa é entrar no contentor em execução e editar o ficheiro aí:
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpNo interior do contentor, /var/www/html/config/config.php está correto. A partir do anfitrião, esse mesmo caminho refere-se ao próprio sistema de ficheiros raiz do anfitrião, e não ao diretório Nextcloud montado.
O aviso de configuração do Docker era um problema separado
Tanto docker inspect como docker exec apresentavam um aviso indicando que /DATA/.docker/config.json não podia ser aberto. A resposta identificou-o como um aviso de configuração da CLI do Docker, e não como a causa do problema de acesso ao ficheiro do Nextcloud. O utilizador conseguiu prosseguir assim que compreendeu a diferença entre o caminho no anfitrião e o caminho no contentor.
FAQ
Por que motivo alterar o proprietário não resolveu o problema do ficheiro de configuração do Nextcloud?
Os comandos estavam a ser aplicados sem confirmar primeiro a origem real da montagem vinculada. Alterar as permissões no diretório errado do anfitrião não afeta o ficheiro dentro do caminho de dados montado do Nextcloud.
O ficheiro config.php deve ser editado a partir do anfitrião ou dentro do contentor?
Ambas as opções podem funcionar. Utilize o caminho de origem completo /DATA/AppData/... a partir do anfitrião, ou entre primeiro no contentor e utilize /var/www/html/.... Não misture os dois contextos de caminho.
