A fonte identifica corretamente a camada de propriedade real: quando um contentor cria uma pasta dentro de uma pasta ZimaOS montada, a nova pasta normalmente herda a identidade e o comportamento de umask do processo em execução dentro do contentor, e não as permissões que esperava que a pasta-pai impusesse automaticamente.
É por isso que uma pasta-pai com permissões de escrita para todos pode continuar a acabar com subpastas novas root:root com 0755. Se a aplicação for executada como root e utilizar uma umask predefinida, é esperado que as pastas-filhas pertençam a root, a menos que a imagem suporte PUID/PGID, um utilizador específico do contentor, herança de grupo setgid, ACL predefinidas ou outro modelo de permissões.
O Exemplo da Fonte Era uma Pasta de Cópias de Segurança Montada
O utilizador descreveu um caminho como:
/media/Daten/Backuponde as subpastas recém-criadas passavam a ser:
root:root
drwxr-xr-xUm utilizador não root, como o UID 999, conseguia então ler, mas não criar ficheiros nessas novas pastas-filhas.
Uma Pasta-Pai 0777 Não Impõe a Propriedade das Pastas-Filhas
A permissão de escrita da pasta-pai permite que o processo do contentor crie uma pasta-filho. Não faz automaticamente com que essa pasta herde o proprietário ou o grupo da pasta-pai, a menos que as regras do sistema de ficheiros/grupo estejam configuradas para esse comportamento.
O UID/GID do criador e a umask do processo determinam o resultado normal.
Utilize PUID/PGID Apenas Quando a Imagem do Contentor os Suportar
Muitas imagens ao estilo LinuxServer disponibilizam as variáveis de ambiente PUID e PGID. Outras imagens ignoram completamente essas variáveis e requerem o campo user: do Docker ou definições específicas da aplicação.
As orientações atuais da IceWhale para o Syncthing indicam explicitamente aos utilizadores que consultem os IDs de utilizador reais do ZimaOS com:
id -u username
id -g usernamee que introduzam esses valores nos campos PUID/PGID da aplicação.
Consulte o exemplo atual de PUID/PGID do ZimaOS.
A umask Controla os Bits de Permissão Removidos na Criação
Uma aplicação que crie pastas com um modo base de 0777 sob uma umask típica de 022 produzirá pastas com 0755. Um fluxo de trabalho de colaboração em grupo pode utilizar uma umask diferente, se a aplicação a suportar.
Não defina uma umask excessivamente permissiva globalmente apenas para corrigir uma aplicação.
O setgid Pode Ajudar a Manter um Grupo Partilhado nas Novas Subpastas
Nos sistemas de ficheiros nativos do Linux, definir o bit setgid numa pasta partilhada pode fazer com que os itens-filhos recém-criados herdem o grupo da pasta. Isto é útil quando vários serviços/utilizadores colaboram intencionalmente através de um único grupo.
Isso não altera o ID de utilizador do processo que cria o item e pode não funcionar da mesma forma em montagens NTFS/exFAT que simulam a propriedade Unix através de opções de montagem.
As ACL Predefinidas Permitem uma Herança Mais Explícita
Nos sistemas de ficheiros que suportam ACL POSIX, as entradas de ACL predefinidas podem definir as permissões que os novos itens-filhos recebem. Isto é frequentemente mais limpo do que executar repetidamente chmod recursivo após cada tarefa de cópia de segurança.
Deve confirmar-se se a interface atual do ZimaOS disponibiliza um fluxo de trabalho completo de ACL para um determinado caminho de armazenamento antes de depender de uma configuração exclusiva da shell.
A Fonte Era um Pedido de Funcionalidade, Não uma Definição Existente do ZimaOS
O autor pediu um controlo global de PUID/PGID, uma opção de herança, tratamento de umask, suporte de setgid e uma interface gráfica para correções recursivas. O tópico não contém nenhuma resposta da IceWhale que confirme a implementação dessas funcionalidades.
Não apresente a lista de pedidos como opções atuais das Definições.
Corrija a Identidade da Aplicação Antes de Alterar Recursivamente Todo o Disco
Se uma aplicação de cópias de segurança recria repetidamente pastas pertencentes a root, executar chown -R após cada tarefa trata o sintoma. Configure primeiro corretamente a identidade, o grupo e a umask do contentor e, em seguida, corrija apenas a árvore afetada.
As definições atuais das aplicações do ZimaOS permitem aos utilizadores consultar os mapeamentos de volumes e a configuração da aplicação, enquanto as variáveis de permissão exatas dependem da imagem.
Perguntas Frequentes sobre a Propriedade de Pastas Montadas
Porque é que uma pasta-filho pode tornar-se root:root dentro de uma pasta-pai com permissões de escrita?
Porque o processo dentro do contentor a criou como root e a pasta-pai não substitui automaticamente a identidade do criador.
O PUID e o PGID funcionam com todas as imagens Docker?
Não. São convenções de variáveis de ambiente específicas das imagens, não variáveis universais do Docker.
A IceWhale confirmou no conteúdo original uma opção global de herança de permissões?
Não. O tópico é um pedido de funcionalidade sem confirmação de implementação.
