Servidor doméstico acessível, mas partilhas de ficheiros expiram: o que deve testar?

Um servidor doméstico acessível pode ainda assim sofrer timeouts em partilhas de ficheiros quando o próprio SMB está bloqueado, parado, mal configurado, sobrecarregado ou preso numa sessão falhada.

O ping prova apenas que o servidor responde a ICMP; não prova que o TCP 445 alcança o ouvinte SMB, que o cliente negocia um protocolo suportado, ou que a partilha pode autenticar e enumerar. O diagnóstico mais rápido avança por camadas: acessibilidade IP, resolução do nome do host, porta 445, estado do serviço SMB, caminho da partilha, credenciais e finalmente carga do servidor durante o timeout.

Compare o IP do Servidor com o Nome da Partilha

Teste a partilha pelo endereço IP atual do servidor e pelo seu nome normal a partir do mesmo cliente. Registe se ambos dão timeout, se apenas o nome falha, ou se o nome resolve para um endereço IPv4 ou IPv6 diferente.

Um caso de suporte OSMC mostrou um host que podia ser pingado enquanto um caminho SMB ainda retornava um timeout de conexão. Essa distinção impede que um ping bem-sucedido elimine prematuramente problemas de DNS, porta ou serviço.

Se o IP funcionar mas o nome falhar, corrija DNS, descoberta multicast, sufixos ou endereços em cache. Se ambos falharem de forma idêntica, continue com o TCP 445 e o ouvinte SMB em vez de limpar repetidamente caches de nomes.

Teste a Porta TCP 445 a partir do Cliente com Falha

Abra um teste de conexão TCP para o endereço do servidor na porta 445 a partir do mesmo dispositivo que experimenta o timeout. Execute-o durante a falha em vez de após reiniciar o NAS ou reconectar o cliente.

Um diagnóstico do Ask Ubuntu separou o ping funcional da falha do Samba verificando se a porta 445 era acessível. O SMB em redes modernas depende desse caminho TCP mesmo quando outros serviços do servidor permanecem disponíveis.

Se a porta 445 der timeout, inspecione a VLAN do cliente, firewall do host, firewall do NAS, ligação da interface e ACLs intermédias. Se conectar imediatamente, o caminho de rede está aberto e o diagnóstico deve avançar para negociação SMB, sessões, credenciais ou estado da partilha.

Confirme que o Serviço SMB Está a Ouvir na Interface Correta

Verifique o estado do serviço SMB e os ouvintes ativos no servidor. Confirme que está ligado ao endereço LAN ou VLAN que o cliente usa, não apenas ao loopback, outra NIC, ponte de container ou um endereço antigo.

Reiniciar todo o NAS pode temporariamente ocultar um serviço parado ou bloqueado. Prefira verificar os registos do serviço, saída dos ouvintes e alterações recentes de configuração antes de reiniciar para que as evidências da falha permaneçam disponíveis.

Se o serviço estiver parado, descubra por que saiu e verifique a configuração da partilha antes de o iniciar novamente. Se estiver a ouvir na interface errada, corrija a ligação e teste novamente a partir do cliente sem alterar regras de firewall não relacionadas.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Separe a Negociação do Protocolo da Autenticação

Use um cliente SMB que reporte o dialeto negociado e o código de erro. Compare um caminho direto da partilha com a navegação na raiz do servidor, porque descoberta, enumeração, autenticação e abertura de uma partilha conhecida são operações separadas.

Um relatório da comunidade Synology descreveu um NAS cujo nome de host e endereço eram acessíveis enquanto a porta SMB 445 falhava nos resultados IPv4 e IPv6.

Se a conexão TCP abrir mas a negociação falhar, compare versões SMB, assinatura, encriptação e compatibilidade do cliente. Se a negociação for bem-sucedida mas a autenticação ficar pendente ou falhar, limpe apenas as credenciais armazenadas relevantes e verifique a conta, ACL da partilha e estado de bloqueio.

Limpe Sessões Obsoletas Sem Apagar Configuração Funcional

Desconecte unidades mapeadas existentes e sessões SMB ativas do cliente com falha, depois reconecte usando um endereço de servidor explícito e conta. Sessões obsoletas podem preservar um endereço antigo, credencial, dialeto ou transporte desconectado.

Verifique a tabela de sessões do servidor ao mesmo tempo. Uma sessão que permanece estabelecida enquanto o cliente dá timeout pode indicar uma conexão TCP semiaberta, cliente em espera, mudança de caminho VPN ou failover de interface que não reiniciou corretamente o estado SMB.

Limpe a sessão individual do cliente antes de reiniciar o serviço SMB para cada utilizador. Se o timeout voltar em novas sessões, continue para carga do servidor e comportamento da rede em vez de tratar a limpeza de sessões como a solução final.

Reproduza o Timeout Enquanto Observa a Carga do Servidor

Monitore CPU, pressão de memória, latência do disco, saúde do pool, filas de rede, atividade de containers, varredura antivírus, indexação e trabalho de snapshots enquanto abre e lista a partilha. Um servidor pode responder a ping enquanto o trabalhador SMB ou caminho de armazenamento espera tempo suficiente para dar timeout.

O guia ZimaSpace para um caminho de serviço NAS sobrecarregado fornece as verificações de desempenho adjacentes após os testes de porta e protocolo terem sucesso.

O problema só está resolvido quando o mesmo cliente consegue conectar, autenticar, listar pastas, ler, escrever, desconectar e reconectar durante a janela de falha. Se o SMB der timeout enquanto a porta 445 permanece aberta e o servidor estiver saturado, corrija o recurso ou gargalo de armazenamento em vez de aumentar os timeouts do cliente.