Por que as permissões de ficheiros deixam de funcionar após mover ficheiros para um NAS?

Os ficheiros podem funcionar normalmente num computador, disco externo ou pasta de downloads e depois tornar-se só de leitura, invisíveis para uma aplicação ou inacessíveis após serem movidos para um NAS. Isso normalmente não significa que os dados do ficheiro estão danificados. Significa que os ficheiros entraram num novo sistema de ficheiros com um modelo diferente de propriedade e permissões.

Uma movimentação entre dispositivos é normalmente realizada como uma cópia seguida da eliminação da origem. O NAS cria novos ficheiros usando a identidade SMB ou NFS ligada, as ACLs da pasta de destino, valores UID e GID, umask, utilizador do contentor e regras de criação do lado do servidor. A forma mais rápida de resolver o problema é identificar quem criou os ficheiros, quem os possui agora e qual utilizador ou processo está a ser negado.

Mover Ficheiros para um NAS Normalmente Cria Novos Ficheiros

Arrastar uma pasta para um NAS pode parecer uma movimentação comum no Windows Explorer ou Finder. Por baixo, no entanto, o disco de origem e o NAS são sistemas de ficheiros separados. O cliente lê os dados originais, cria novos objetos no destino e elimina os originais após a transferência ser bem-sucedida.

Isto difere de mover um ficheiro entre duas pastas no mesmo sistema de ficheiros, onde o sistema pode apenas atualizar a localização do ficheiro no diretório. A descrição da Microsoft sobre o comportamento de copiar e mover explica que os objetos copiados para outro volume herdam as permissões da nova pasta, enquanto uma movimentação no mesmo volume normalmente mantém as permissões existentes.

Essa distinção explica porque “Cortar e Colar” não garante que a propriedade, as entradas ACL ou os atributos estendidos permaneçam idênticos após uma transferência para um NAS. O sistema de destino não está simplesmente a realocar o objeto original do sistema de ficheiros.

As ACLs do Destino Decidem o Que os Novos Ficheiros Herdam

Se cada ficheiro recém-copiado receber as mesmas permissões inesperadas, o diretório pai é geralmente mais importante do que o ficheiro de origem. O destino pode ter entradas ACL herdadas, ACLs POSIX padrão, flags ACL NFSv4 ou predefinições de permissões específicas de NAS.

Por exemplo, uma pasta partilhada pode ser configurada para que os novos ficheiros herdem o acesso para um grupo familiar, um grupo de multimédia ou uma conta SMB específica. A ausência da flag de herança pode criar o resultado oposto: os utilizadores podem aceder à raiz do conjunto de dados, mas não aos novos ficheiros dentro dela.

Os sistemas de permissões ao estilo TrueNAS distinguem os modelos POSIX e ACLs NFSv4/SMB. O comportamento importante é que a herança de ACL NFSv4 e SMB pode controlar novos ficheiros e pastas, enquanto os padrões POSIX e os limites do conjunto de dados se comportam de forma diferente. Antes de alterar ficheiros individuais, inspecione a ACL e as flags de herança na pasta de destino.

O NAS Usa a Conta SMB Conectada

Quando um computador Windows ou macOS copia um ficheiro via SMB, o NAS normalmente não preserva a identidade local do utilizador do computador cliente. Cria o ficheiro de destino como a conta autenticada no compartilhamento SMB, ou como uma conta à qual essa sessão está mapeada.

É por isso que um ficheiro pertencente a um utilizador Windows no PC de origem pode pertencer a kenneth, nasuser, guest, ou outra identidade do lado NAS após a transferência. Uma credencial SMB guardada também pode fazer com que um computador crie ficheiros sob um proprietário diferente do de outro computador.

Verifique o nome de utilizador SMB ativo em vez de presumir que está a ser usado o login do ambiente de trabalho. Desconecte o compartilhamento, limpe credenciais obsoletas se necessário, e reconecte com a conta NAS que deve possuir ou gerir os ficheiros.

Acesso ao Compartilhamento e Acesso ao Ficheiro São Camadas de Permissão Separadas

Um utilizador pode conseguir abrir o compartilhamento SMB e navegar pelas pastas, mas ainda assim não conseguir editar, renomear ou eliminar um ficheiro. Isto significa que o compartilhamento de rede é acessível; não prova que o sistema de ficheiros concedeu a operação solicitada.

Regras ao nível do compartilhamento determinam se um cliente SMB ou NFS pode aceder ao compartilhamento e se a conexão é apresentada como só leitura ou leitura/escrita. O sistema de ficheiros subjacente avalia então o proprietário, grupo, bits de modo, entradas ACL e regras de herança para cada ficheiro e diretório.

Resolva problemas em ambas as camadas. Um compartilhamento marcado como leitura/escrita não pode sobrepor uma ACL do sistema de ficheiros que nega escrita, e modos permissivos do sistema de ficheiros não ajudam quando a conta SMB é restringida pela configuração do compartilhamento.

ACLs ao Estilo Windows e Modos POSIX Não Correspondem Perfeitamente

as permissões do Windows possam conter múltiplos utilizadores e grupos, entradas explícitas de permissão e negação, flags de herança e direitos separados para leitura, escrita, eliminação e modificação. Os bits de modo POSIX tradicionais reduzem o acesso a proprietário, grupo e outros.

Sistemas operativos Samba e NAS devem traduzir entre esses modelos. Um painel de Segurança do Windows pode mostrar uma ACL detalhada mesmo que ls -l exibe apenas uma representação simplificada. Por outro lado, executar chmod pode alterar bits de modo sem reconstruir corretamente a ACL ao estilo Windows que os clientes SMB esperam.

Se o conjunto de dados NAS usar ACLs NFSv4 ou SMB, inspecione a ACL completa através da interface NAS ou de um comando que reconheça ACLs. Não presuma que um ficheiro que mostra rwxrwx--- explica toda a história das permissões.

Incompatibilidades entre UID e GID Afetam Linux, NFS e Aplicações

Sistemas Linux geralmente determinam a propriedade através de IDs numéricos de utilizador e grupo. O nome de utilizador é apenas um rótulo associado a esses números.

Dois sistemas podem ambos mostrar um utilizador chamado media enquanto um usa UID 1000 e o outro usa UID 1001. Para Linux e NFS, essas são identidades diferentes. Um ficheiro pertencente ao UID 1000 pode ser inacessível a uma aplicação a correr como UID 1001 mesmo quando os nomes de utilizador visíveis parecem idênticos.

Verifique os valores numéricos no NAS, anfitrião, cliente e aplicação:

id media
ls -ln /path/to/files
stat /path/to/files/example.mkv

Compare os números em vez de apenas os nomes exibidos. Se múltiplos sistemas precisam de escrever no mesmo armazenamento, alinhe os valores UID/GID necessários ou crie um grupo partilhado com as permissões corretas.

SMB e NFS Podem Escrever o Mesmo Conjunto de Dados Como Utilizadores Diferentes

Problemas de permissão aparecem frequentemente gradualmente quando clientes SMB e NFS têm ambos acesso de escrita ao mesmo diretório. Ficheiros carregados via SMB podem pertencer a um utilizador NAS, enquanto ficheiros criados via NFS podem ter um UID numérico de outro sistema.

Os dois protocolos também podem aplicar regras diferentes de ACL e mapeamento de identidade. Como resultado, uma pasta pode conter ficheiros que parecem idênticos para um utilizador mas têm proprietários, grupos, máscaras ou entradas herdadas diferentes.

Escolha um protocolo de escrita principal sempre que possível. Quando SMB e NFS têm de partilhar um conjunto de dados, alinhe os IDs numéricos, grupos partilhados, ACLs padrão, valores umask e comportamento de criação antes de colocar dados de produção nele.

Contentores Docker Adicionam Outra Identidade de Utilizador

Um ficheiro pode ser legível através de SMB mas indisponível para Plex, Jellyfin, Nextcloud, um descarregador ou um contentor de backup. O Docker pode montar o caminho correto enquanto o processo dentro do contentor ainda não tem permissão para o ler ou escrever.

Um processo de contentor corre sob um UID e GID próprios. Se essa identidade não corresponder ao proprietário ou a um grupo autorizado no caminho NAS montado, a aplicação recebe Permissão negada. Uma montagem de volume torna o diretório visível; não contorna a autorização do sistema de ficheiros.

Uma solução comum é igualar o UID e GID do contentor com a identidade autorizada a usar o volume montado. Verifique a identidade real do processo em vez de confiar apenas num campo PUID ou PGID mostrado num ficheiro Compose:

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "Gravável"

Um Contentor Pode Criar Ficheiros Que Outro Não Consegue Ler

Isto acontece frequentemente em pilhas de automação de media. Um contentor de download escreve com sucesso um ficheiro concluído, mas o servidor de media não consegue digitalizá-lo, ou um organizador não consegue renomeá-lo.

As aplicações podem usar valores UID/GID diferentes ou umasks diferentes. Se o descarregador cria ficheiros como 600, apenas o seu proprietário pode ler e escrever neles. Um modo como 640 permite leitura pelo grupo, mas apenas quando ambas as aplicações partilham o grupo correto.

Para diretórios de aplicações partilhadas, use um grupo proprietário planeado, adicione as identidades necessárias da aplicação a esse grupo e selecione uma umask que dê ao grupo o acesso necessário. Corrigir apenas ficheiros antigos não ajudará se o descarregador continuar a criar novos ficheiros com modos restritivos.

Umask e regras de criação do servidor controlam novas permissões

Se ficheiros antigos funcionam mas cada novo ficheiro é inacessível, o processo de criação é a causa provável. Cada programa começa com um modo de ficheiro solicitado, e a sua umask remove permissões selecionadas antes do ficheiro ser criado.

O Samba pode também usar definições como máscara de criação, máscara de diretório, forçar utilizador, ou forçar grupo. As interfaces NAS podem ocultar estes atrás de modelos de permissões, predefinições de pastas partilhadas ou opções de herança.

Crie um ficheiro de teste por cada caminho: Windows SMB, macOS SMB, gestor de ficheiros NAS, NFS e cada contentor relevante. Compare o proprietário, grupo, modo e ACL resultantes. Isto revela rapidamente qual caminho de criação produz permissões incorretas.

Diferentes ferramentas de transferência preservam diferentes metadados

Finder, Windows Explorer, uma interface web NAS, cp, e rsync não garantem resultados idênticos. Alguns preservam carimbos de data/hora, outros podem reter modos POSIX, e outros simplesmente criam novos ficheiros sob as regras do destino.

Antes de escolher um método de migração, decida quais propriedades devem ser mantidas:

• Conteúdos dos ficheiros e estrutura de diretórios
• Tempos de modificação
• Permissões POSIX
• Proprietário e grupo
• Entradas ACL
• Atributos estendidos
• Links simbólicos

Para documentos familiares comuns ou ficheiros multimédia, a herança no destino pode ser preferível à preservação de contas do computador de origem que não existem no NAS. Para dados de aplicações, diretórios home Linux ou migrações de servidores, preservar a propriedade e os metadados ACL pode ser essencial.

O Rsync não preserva todos os atributos com um comando básico

O Rsync é útil para migrações controladas de NAS, mas o resultado depende das suas opções, dos privilégios do utilizador que executa e das capacidades dos sistemas de ficheiros de origem e destino.

O modo de arquivo preserva metadados comuns, incluindo modos, carimbos de data/hora, grupos e propriedade, quando permitido. Opções adicionais são necessárias quando a migração deve preservar permissões, ACLs e atributos estendidos com rsync. Um teste típico de Linux para Linux pode usar:

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

O -A a opção preserva ACLs e -X preserva atributos estendidos quando ambos os lados os suportam. --numeric-ids deve ser usado deliberadamente porque preservar um proprietário numérico que não tem uma conta válida no NAS pode reproduzir exatamente a incompatibilidade que está a tentar evitar.

Um Destino Rsync Montado via SMB Pode Não Comportar-se Como o Sistema de Ficheiros NAS

Executar rsync a partir de um computador para uma partilha SMB montada localmente nem sempre é equivalente a executar rsync via SSH diretamente contra o sistema de ficheiros NAS. A camada SMB pode mapear proprietários, transformar ACLs ou rejeitar tentativas de definir atributos.

O utilizador que realiza a cópia SMB pode não ter permissão para atribuir propriedade arbitrária, mesmo quando o rsync o solicita. O sistema de ficheiros de destino pode também suportar um modelo de ACL diferente do de origem.

Teste primeiro um diretório representativo pequeno. Examine os ficheiros diretamente no NAS após a transferência, não apenas através da partilha montada no cliente. Confirme a propriedade, modos, ACLs, atributos estendidos e acesso da aplicação antes de migrar o conjunto de dados completo.

Predefinições de Permissões NAS Podem Substituir Bits de Modo Simples

Alguns sistemas NAS gerem o acesso através de modelos de ACL do conjunto de dados e metadados estendidos, em vez de apenas os modos tradicionais de proprietário/grupo/outros. Isto pode tornar uma gestão manual chmod parecem bem-sucedidas enquanto o SMB ou uma aplicação continua a negar o acesso.

Um conjunto de dados também pode estar configurado para reaplicar regras herdadas quando novos ficheiros são criados ou quando as permissões são editadas através da interface de gestão. Misturar ACLs geridas pela GUI com alterações repetidas na linha de comandos pode produzir um estado inconsistente.

Escolha um modelo de permissão e gere-o de forma consistente. Se o conjunto de dados estiver configurado para uma ACL SMB/NFSv4, use o editor de ACL do NAS ou ferramentas compatíveis com ACL em vez de substituir repetidamente a estrutura com comandos de modo POSIX.

Reinstalar o NAS Não Necessariamente Redefine as Permissões dos Dados

As permissões geralmente pertencem aos ficheiros e ao conjunto de dados do sistema de ficheiros, não apenas à configuração do sistema operativo NAS. Reinstalar o sistema de arranque pode, portanto, deixar as mesmas entradas de propriedade e ACL inacessíveis num pool de armazenamento importado.

Um caso da comunidade TrueNAS ilustra como as permissões do sistema de ficheiros permanecem associadas ao pool de armazenamento e devem ser correspondidas com os utilizadores corretos e a configuração de acesso adequada. Também mostra o risco de fazer grandes alterações recursivas sem primeiro compreender o modelo de identidade pretendido.

Antes de reinstalar ou reconstruir serviços, inspecione o proprietário do conjunto de dados, grupo, ACL e utilizadores da aplicação. Os dados podem estar intactos e apenas requerer que as suas regras de acesso sejam restauradas corretamente.

Por que o chmod 777 recursivo não é uma correção real

Quando milhares de ficheiros ficam inacessíveis, chmod -R 777 parece uma forma rápida de restaurar o acesso. Concede permissão de leitura, escrita e execução ao proprietário, grupo e todas as outras identidades locais.

Isso pode expor dados privados, permitir que serviços não relacionados modifiquem ficheiros, definir permissão de execução em documentos comuns e danificar uma estrutura ACL cuidadosamente herdada. Também não corrige o proprietário errado, UID do contentor incompatível, falta de pertença a grupo ou mapeamento de identidade SMB quebrado.

Use o modelo de acesso pretendido: estabeleça o proprietário correto e grupo partilhado, reconstrua a ACL apropriada, defina modos de diretório e ficheiro separadamente e corrija a herança futura e definições de umask. Teste numa pasta pequena antes de aplicar alterações recursivas.

Reparar permissões a partir da identidade para fora

Comece pelo utilizador ou processo negado em vez do comando que espera que corrija o problema. Um utilizador SMB humano, um servidor de media e um contentor de backup podem requerer níveis diferentes de acesso.

Para cada fluxo de trabalho afetado, registe:

• O utilizador ou processo que tenta aceder
• O seu UID e GID numéricos, quando aplicável
• O protocolo ou montagem usada
• O proprietário e grupo atuais do ficheiro
• A ACL completa e entradas herdadas
• O acesso realmente necessário: ler, criar, modificar ou eliminar

Depois modifique apenas a camada que está errada. Adicione o utilizador a um grupo permitido, corrija a propriedade, repare a ACL, alinhe o UID do contentor ou atualize a regra de criação. Evite conceder acesso mais amplo do que o necessário para o fluxo de trabalho.

Seguir uma ordem de resolução de problemas em camadas

Alterar a ACL da partilha, identidade do contentor, exportação NFS e modos de ficheiro ao mesmo tempo destrói evidências úteis. Teste uma camada de permissões de cada vez.

Comece com um ficheiro afetado e um utilizador ou aplicação afetados. Depois de esse caso pequeno funcionar, crie um novo ficheiro pelo fluxo normal e confirme que a correção também impede o problema de voltar.

Previna Problemas de Permissões Antes de uma Grande Migração NAS

Reparar permissões em centenas de milhares de ficheiros é muito mais difícil do que testar o modelo de acesso antes da migração. Crie uma pequena pasta de destino com o mesmo ACL e configuração de aplicação planeada para o conjunto final de dados.

Copie vários tipos de ficheiros, diretórios aninhados, ficheiros só de leitura, scripts executáveis e ficheiros com atributos estendidos. Teste-os a partir de cada caminho necessário: SMB, NFS, a interface NAS, software de backup e contentores relevantes.

Só comece a migração completa depois de os novos ficheiros receberem consistentemente o proprietário, grupo, ACL e acesso da aplicação corretos. Mantenha uma snapshot ou backup antes de aplicar quaisquer alterações recursivas de propriedade ou permissões aos dados existentes.

Conclusão Final

As permissões dos ficheiros ficam corrompidas após mover dados para um NAS porque a transferência normalmente cria novos objetos no sistema de ficheiros. Esses objetos são governados pela conta NAS usada para a transferência, pelo ACL de destino, valores UID/GID, umask, mapeamento de protocolo e identidade da aplicação ou contentor.

Não comece com chmod 777Primeiro responda a três perguntas: quem criou o ficheiro, quem é o proprietário atual e a que identidade está a ser negado o acesso. Depois, inspecione o acesso à partilha, ACLs do sistema de ficheiros, herança, IDs do contentor e regras futuras de criação.

Uma reparação bem-sucedida deve fazer duas coisas: restaurar o acesso apropriado aos ficheiros existentes e garantir que o próximo ficheiro copiado, descarregado ou criado no NAS receba automaticamente as permissões corretas.

FAQ

Por que é que os ficheiros copiados herdam as permissões da pasta NAS?

Uma transferência para um NAS normalmente cria novos ficheiros num sistema de ficheiros diferente. Os novos objetos são geralmente atribuídos permissões a partir do ACL da pasta de destino, flags de herança e regras de criação do lado do servidor.

Por que é que consigo abrir ficheiros NAS via SMB mas o meu contentor Docker não?

A sessão SMB e o contentor usam identidades diferentes. Verifique o UID e GID reais do contentor, a propriedade numérica do caminho montado, a pertença ao grupo e se a montagem é só de leitura.

Devo usar chmod 777 para reparar uma partilha NAS?

Não. Concede a todas as identidades locais um acesso amplo, pode danificar a herança de ACL e não resolve a propriedade incorreta ou o mapeamento UID/GID. Defina os utilizadores e grupos pretendidos, depois repare a propriedade e as ACLs em conformidade.

O rsync pode preservar permissões de ficheiros NAS?

Pode preservar permissões POSIX e outros metadados quando as opções selecionadas, os privilégios de execução e ambos os sistemas de ficheiros os suportam. ACLs e atributos estendidos requerem opções adicionais, como -A e -X.

Por que é que os novos ficheiros continuam a ficar corrompidos depois de reparar os ficheiros antigos?

O caminho de criação ainda está errado. Verifique o ACL herdado da pasta de destino, a identidade SMB ou NFS, o umask da aplicação, as regras de criação do Samba e o UID/GID do contentor.