Porque é que uma partilha NAS mostra ficheiros antigos depois de a pasta ser substituída?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Uma partilha NAS pode mostrar ficheiros antigos quando o cliente ou o serviço de partilha ainda aponta para um estado de diretório em cache ou para o caminho anterior.

Substituir uma pasta no NAS não garante que todas as sessões SMB, aplicações, montagens, caminhos inversos ou espaços de nomes mudem imediatamente para a nova árvore de diretórios. O servidor pode ainda exportar o caminho antigo, a substituição pode ter sido feita sob uma montagem diferente ou o cliente pode manter metadados de diretório, informações de ficheiros, identificadores abertos ou uma referência em cache. O diagnóstico mais seguro compara a vista do sistema de ficheiros, o destino ativo da partilha e uma sessão de cliente completamente nova antes de alterar qualquer definição de cache.

Confirme qual camada ainda mostra a árvore de diretórios antiga

Compare o cliente SMB afetado com a shell do NAS, o gestor de ficheiros Web do NAS e um segundo cliente que não tenha aberto a partilha recentemente. Registe um nome de ficheiro que deveria ter desaparecido e um nome de ficheiro novo que deveria estar visível.

Se a shell do NAS e o gestor de ficheiros Web também mostrarem a árvore antiga, o problema está abaixo do SMB: a substituição ocorreu no diretório errado, falta uma montagem esperada ou outro conjunto de dados está a sobrepor-se ao caminho. A IBM observa que as notificações de alteração SMB dependem da forma como as alterações chegam ao serviço de ficheiros, pelo que um único cliente desatualizado não prova, por si só, que os dados do servidor sejam antigos.

Não atualize repetidamente o mesmo navegador de ficheiros, tratando isso como um novo teste. Uma comparação relevante utiliza outro processo de cliente, outra sessão de utilizador ou uma vista direta do sistema de ficheiros local que não reutilize os mesmos metadados SMB.

Verifique o destino ativo da partilha depois de substituir a pasta

Inspecione a configuração de partilhas do servidor e resolva o caminho exportado para o objeto real do sistema de ficheiros. Verifique montagens vinculadas, ligações simbólicas, pontos de montagem de conjuntos de dados, mapeamentos de volumes de contentores e se a pasta de substituição foi criada antes ou depois de uma montagem de armazenamento ficar ativa.

Uma falha comum ocorre quando o administrador substitui ficheiros dentro de um diretório desmontado e, em seguida, a montagem de armazenamento real regressa e oculta essa substituição. O manual de montagem do Linux explica que montar oculta a vista anterior do diretório enquanto o sistema de ficheiros permanece associado, razão pela qual o caminho visível deve ser verificado em comparação com a tabela de montagens ativa.

O guia de migração de dados NAS da ZimaSpace apresenta a sequência de verificação complementar para comprovar que os caminhos de origem e destino pretendidos contêm os dados esperados antes de remover a cópia antiga.

Teste as caches SMB de diretórios e informações de ficheiros

Feche todas as aplicações que utilizam a partilha, desligue o mapeamento SMB e estabeleça uma nova sessão. Compare o resultado com um segundo computador ou uma nova sessão de utilizador que ainda não tenha enumerado o diretório.

Os clientes SMB do Windows podem colocar em cache os metadados de diretórios e as informações de ficheiros durante um período configurado. As orientações da Microsoft para otimização de servidores de ficheiros explicam que o tempo de vida da cache de diretórios controla durante quanto tempo os metadados podem permanecer em cache quando não estão disponíveis concessões de diretório.

Se uma sessão nova mostrar imediatamente a árvore correta enquanto a sessão antiga não o faz, os dados não estão em falta e o destino da partilha está provavelmente correto. Volte a ligar o cliente afetado de forma limpa e investigue por que motivo a sessão não recebeu ou não respeitou a notificação de alteração esperada antes de alterar globalmente os valores da cache.

-15% OFF

Verifique identificadores abertos, concessões e aplicações de longa duração

Liste as sessões SMB ativas e os ficheiros abertos no NAS. Gestores de multimédia, aplicações de fotografias, ferramentas de cópia de segurança, janelas de shell, indexadores e navegadores de ficheiros podem manter diretórios ou ficheiros abertos muito depois de terminar a operação de cópia visível.

Feche primeiro a aplicação e, em seguida, desligue apenas a sessão SMB afetada. A documentação SMB da NetApp explica que os oplocks de concessão preservam o estado da cache do cliente, pelo que desativar as concessões em todo o NAS é uma alteração muito mais abrangente do que repor uma ligação desatualizada.

Se a árvore antiga desaparecer apenas depois de fechar uma aplicação específica, preserve esse resultado e volte a testar a aplicação com a nova pasta. A ação corretiva deve incidir no comportamento de ligação, monitorização ou atualização da aplicação, e não no conjunto de armazenamento.

Exclua referências DFS e nomes de servidor duplicados

Verifique se o cliente chegou ao NAS através de um nome de anfitrião direto, de um endereço IP, de um alias DNS, de um espaço de nomes DFS ou de um nome de servidor antigo que agora resolve para outro local. Dois caminhos que parecem semelhantes no navegador de ficheiros podem terminar em destinos de partilha diferentes.

Os clientes DFS colocam em cache as referências de espaços de nomes e pastas durante um período definido. Os clientes DFS também podem manter referências de espaços de nomes e pastas durante algum tempo, o que pode enviar temporariamente um cliente para um destino antigo depois de uma alteração no espaço de nomes.

Compare a identidade do servidor, o endereço resolvido, o nome da partilha e o caminho final das sessões funcionais e desatualizadas. Não limpe todas as caches DNS e DFS antes de provar que o cliente afetado está a chegar a um destino diferente.

Compare um caminho direto novo com o caminho normal do utilizador

Abra a partilha uma vez através do nome de anfitrião normal e outra vez através do endereço direto verificado do servidor, utilizando uma sessão de cliente limpa. Utilize este procedimento apenas como elemento de distinção, não como substituição permanente de um nome de anfitrião gerido.

Se o caminho direto mostrar a árvore nova enquanto o nome normal mostra a antiga, concentre-se nos aliases, nas referências, nas credenciais guardadas ou noutro NAS que utilize o mesmo nome. O modelo de caminho mount.cifs do Debian mostra por que motivo é necessário comparar o destino exato do servidor e da partilha com o ponto de montagem local, em vez de depender de um nome familiar apresentado no ecrã.

Compare também a contagem de ficheiros e o hash de um ficheiro no caminho local do NAS e no caminho SMB. Um ficheiro antigo igual confirma a seleção de caminho ou cache; um ficheiro diferente com o mesmo nome aponta para uma substituição incompleta, pastas duplicadas ou conteúdo gerado pela aplicação.

Corrija a falha mais pequena e confirme que resiste ao reinício

Corrija o destino da partilha quando este exportar a pasta errada, restaure a montagem em falta quando o caminho estiver incorretamente coberto, volte a ligar a sessão de cliente desatualizada quando apenas um cliente for afetado ou atualize o destino DFS quando o espaço de nomes ainda referenciar a localização antiga.

Evite alterar os tempos de vida da cache SMB, desativar concessões ou recriar a partilha, a menos que um teste controlado prove que essa camada é responsável. A vista de sessões e bloqueios ativos do Samba permite verificar a ligação afetada antes de aplicar uma alteração em todo o servidor.

O problema está resolvido quando a shell do NAS, o gestor de ficheiros Web, a sessão SMB nova e o caminho normal do cliente mostram todos o mesmo conteúdo de pasta depois de reiniciar o serviço e o anfitrião. Mantenha a pasta antiga offline, mas intacta, até essa verificação ser concluída e nenhuma aplicação continuar a escrever nela.

Suporte e Dicas

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.