Solução da comunidade

Novos utilizadores do ZimaOS recebem «Permissão negada» em ficheiros partilhados: o que verificar

A March 2026 multi-user case where an administrator could access data but a newly created member received permission errors even after read/write access was assigned. The thread ended without a confirmed root cause.

Se for concedido a um novo membro do ZimaOS acesso de Leitura e escrita na interface de partilha, mas este continuar a receber a mensagem «acesso negado», não execute imediatamente comandos recursivos de alteração de propriedade em todo o conjunto de armazenamento. A discussão de origem de março de 2026 testou várias teorias sobre a propriedade, efetuou uma reposição completa e, ainda assim, não chegou a uma causa-raiz confirmada.

O método de resolução de problemas mais sólido consiste em separar a camada de permissões do ZimaOS/Samba da camada subjacente de propriedade do Linux. Reproduza primeiro o problema numa pequena pasta nova, compare o acesso do administrador e do membro e só depois inspecione o caminho exato no anfitrião.

A permissão do membro parecia correta na interface

A conta de administrador conseguia aceder aos dados, enquanto uma conta recém-criada com o nome Andres recebeu acesso de leitura/escrita, mas encontrou um erro de permissão ao abrir ficheiros.

A conta de membro do ZimaOS recebe a mensagem de acesso negado ao aceder aos ficheiros partilhados
O sintoma original era uma conta de membro receber acesso negado, apesar de o administrador conseguir aceder ao mesmo armazenamento.
Definições de membro do ZimaOS que mostram as permissões de acesso do utilizador afetado
O utilizador de origem já tinha configurado o acesso de membro na interface do ZimaOS.

O ZimaOS atual suporta permissões do Samba por utilizador

A documentação atual do ZimaOS distingue o acesso de membros do acesso de convidados e permite que um gestor atribua permissão de Leitura ou de Leitura e escrita a uma partilha Samba. Um membro com Leitura e escrita deverá conseguir transferir, carregar, mudar o nome e eliminar ficheiros dentro da partilha, desde que o sistema de ficheiros subjacente esteja acessível.

A configuração atual do Samba multiutilizador no ZimaOS é o ponto de partida correto antes de utilizar correções ao nível da shell copiadas de uma discussão antiga.

Reproduzir o problema numa pasta de teste recém-criada

Crie uma pequena pasta de teste através da interface atual de Ficheiros no disco de dados pretendido. Partilhe apenas essa pasta com o novo membro, atribuindo-lhe Leitura e escrita, e ligue-se a partir do dispositivo do membro utilizando as credenciais desse membro.

Se a pasta de teste funcionar, mas os diretórios migrados ou mais antigos falharem, o problema está provavelmente relacionado com esses caminhos ou com a respetiva propriedade. Se a pasta recém-criada na interface também falhar, o problema é mais abrangente e deve ser tratado como um possível problema de conta, Samba ou permissões do ZimaOS, e não como um problema de propriedade de ficheiros antigos.

Painel de gestão do Samba no ZimaOS utilizado para consultar o acesso às partilhas
Utilize a camada de gestão de partilhas para verificar qual o membro que tem acesso antes de alterar a propriedade do sistema de ficheiros.

Utilize a propriedade do Linux como sinal de diagnóstico, não como correção cega

O tópico analisou os IDs de utilizador e a propriedade dos diretórios e encontrou caminhos em /DATA/.media pertencentes a diferentes utilizadores e grupos Linux. Isso tornou plausível uma incompatibilidade de propriedade nos dados migrados.

Saída do terminal que mostra a propriedade dos diretórios de dados do ZimaOS durante a resolução de problemas de permissões
A comunidade comparou a propriedade dos diretórios depois de a definição de permissões na interface não ter explicado a falha.

Uma sugestão recursiva chown A operação produziu então muitos erros «Operação não permitida» dentro de dados geridos por aplicações. Isto é um aviso contra a aplicação de um único comando de propriedade a árvores amplas do sistema ou do AppData. A alteração recursiva da propriedade pode danificar contentores ou serviços que dependam de UID e GID específicos.

Utilize id, ls -lde um pequeno ficheiro de teste para compreender o caminho exato que está a falhar. Não altere diretórios de aplicações não relacionados.

A reposição de fábrica não foi uma solução confirmada

Menu de reposição do ZimaOS utilizado durante a investigação das permissões
O utilizador acabou por testar uma reposição em vez de continuar a modificar a árvore migrada.
Caixa de diálogo de confirmação da reposição do ZimaOS apresentada no tópico original
A reposição foi uma experiência no tópico, não uma solução comprovada.

Após a reformatação e reinstalação, o autor continuou a relatar erros de permissão do membro. Esse resultado é importante: não recomende uma reposição destrutiva como solução normal para um problema de acesso de utilizador.

A instalação limpa do ZimaOS continua a apresentar um erro de acesso negado para um membro
O teste de instalação limpa não demonstrou que a reposição ou a reformatação resolvessem o problema de acesso do membro.
Definições de acesso de membros do ZimaOS recém-instalado utilizadas após a reinstalação
As permissões do membro foram recriadas após a reinstalação, mas o tópico continuou sem chegar a uma causa confirmada.

O que recolher antes de comunicar o problema

Se uma nova pasta criada através do ZimaOS atual continuar a falhar para um membro recém-criado, registe a versão do ZimaOS, o caminho da partilha, a definição das permissões do membro, o sistema operativo do cliente, o erro exato e se o acesso de administrador funciona. Registe também o resultado de id para a conta relevante e ls -ld apenas para o caminho afetado.

Essa evidência é mais útil do que outra alteração abrangente de propriedade. O tópico original terminou com a comunidade a considerar inesperada e merecedora de uma investigação mais aprofundada uma reprodução após uma instalação limpa, não com uma correção de uma só linha verificada.