Você conecta a VPN, abre a unidade mapeada e falta na pasta um arquivo que o servidor claramente tem. O primeiro instinto é culpar o túnel, o DNS ou as permissões do Samba. Em muitos casos a conexão está boa e o Explorador mostra uma cópia em cache do compartilhamento. Os Arquivos Offline podem servir essa cópia mesmo com a VPN ativa, porque é o compartilhamento, e não o túnel, que decide se a exibição está atualizada. A correção começa por provar qual dos dois você está vendo.

O mito: um ícone de VPN significa que o compartilhamento está atualizado

O ícone da VPN informa que existe um túnel até o ponto de extremidade. Ele não diz nada sobre se um compartilhamento SMB específico está acessível, se o Explorador devolveu esse compartilhamento ao modo online ou se uma sincronização falhada deixou uma cópia mais antiga no lugar. Também não informa qual servidor uma rota DFS escolheu.

Os Arquivos Offline mantêm uma cópia local dos compartilhamentos redirecionados ou fixados para que continuem disponíveis quando o servidor não está acessível. Quando o compartilhamento volta, o cliente deve voltar ao modo online e sincronizar. Uma política de ligação lenta pode decidir que a conexão ainda está lenta demais e manter a exibição em cache, e um conflito pendente pode fazer o mesmo mesmo numa ligação rápida.

Por isso o sintoma parece seletivo: uma pasta está desatualizada, outra abre corretamente e uma terceira não abre de forma alguma. São três estados diferentes, e só o primeiro é a história de cache tratada neste artigo. Nomeie o estado antes de escolher uma correção.

Prove qual destino o Explorador está lendo

Comece pelo caminho UNC exato em vez da letra da unidade. Uma unidade mapeada pode apontar para um compartilhamento diferente do que você pensa, e um caminho DFS pode referir-se a um servidor completamente diferente. Ler o mapeamento mostra o destino guardado e o respetivo estado:

Get-SmbMapping | Select-Object LocalPath, RemotePath, Status
Get-SmbConnection
net use

Abra o caminho UNC diretamente numa nova janela do Explorador e compare-o com a unidade mapeada. Se o caminho direto mostra o arquivo atual e a unidade mapeada não, o mapeamento faz parte do problema, não a cache.

Depois confirme que o arquivo existe para o utilizador pretendido. Uma listagem de administrador no servidor prova a existência, não que o utilizador SMB comum tenha o mesmo acesso, por isso verifique com a conta que realmente usa o compartilhamento. Credenciais diferentes produzem vistas diferentes por motivos que nada têm a ver com a cache. Existência, acesso e visibilidade são três verificações separadas.

Leia o estado de sincronização antes de apagar qualquer coisa

O Centro de Sincronização, onde a funcionalidade está disponível, informa se o compartilhamento funciona offline, se a última sincronização falhou e se há conflitos à espera. Esses três estados levam a correções diferentes, e apagar a cache enquanto um conflito está pendente pode descartar trabalho local.

Procure alterações locais que não chegaram ao servidor antes de desativar a cache, desfixar o compartilhamento ou eliminar a cópia offline. Um arquivo que só existe na cache não é uma vista desatualizada; são dados não sincronizados, e devem primeiro ser preservados através do processo aprovado. Uma cache com alterações pendentes não é segura de apagar.

Quando o trabalho local estiver seguro, use a transição online e a sincronização suportadas, e depois compare novamente a listagem. Abrir uma segunda janela do Explorador não força uma atualização, porque ambas as janelas podem ler a mesma cache local.

Corrija o estado do compartilhamento em vez de eliminar a funcionalidade

Se o compartilhamento permanecer offline por causa de uma política de ligação lenta, ajuste a política para esse compartilhamento ou rede em vez de desativar os Arquivos Offline para todos os utilizadores. Se a sincronização continuar a falhar, corrija a falha e resolva os conflitos; uma sincronização a funcionar é o que torna a cópia em cache atualizada de novo. Altere a menor política que cobre o compartilhamento. Uma alteração global troca a vista desatualizada de um utilizador pela perda de acesso offline de todos.

Para compartilhamentos que nunca devem ser colocados em cache, o servidor pode enviar uma sugestão por compartilhamento. O Samba expõe-na como parâmetro do compartilhamento, e o valor para um compartilhamento que deve permanecer apenas online é:

csc policy = disable

referência de parâmetros do Samba define os valores permitidos e o seu significado. Aplique a definição através do gestor de compartilhamentos que realmente gera a configuração, sobretudo num NAS, e lembre-se de que a sugestão não repara dados já colocados em cache num cliente.

Após qualquer alteração de política, verifique que o cliente se volta a ligar e que o arquivo esperado aparece. Um serviço reiniciado não é prova de que uma alteração local pendente foi carregada, por isso verifique o arquivo, não apenas o estado da ligação.

Quando a causa não são os Arquivos Offline

Se o caminho UNC estiver confirmado online e uma listagem nova continuar a divergir, a cache não é a explicação. Verifique as permissões do compartilhamento e do sistema de arquivos, a enumeração baseada em acesso e o servidor que uma referência DFS realmente escolheu. Qualquer um deles pode esconder uma pasta sem que exista uma cópia local.

Um compartilhamento que nunca liga precisa de provas de encaminhamento e de filtragem de serviços, não de uma verificação de cache. A porta 445 bloqueada pelo túnel, um nome DNS que resolve para o endereço errado ou uma regra de firewall que permite ping mas não SMB produzem todos uma falha antes de a cache importar.

O teste que separa as duas famílias é simples: uma pasta que existe no servidor, é visível para o utilizador certo e ainda assim não aparece online aponta para política ou enumeração; uma pasta que aparece com conteúdo antigo aponta para a cache. Diagnostique a família antes de alterar uma definição.

Artigos relacionados