Meu cliente Win7 tem uma conexão com um servidor Linux e suas pastas compartilhadas. O problema ocorre quando o computador é ativado após uma suspensão e, em seguida, uma das pastas compartilhadas não está acessível. Eu recebo a seguinte mensagem: Código de erro: 80070035, O caminho de rede não foi encontrado.
Eu tenho problema com apenas uma pasta específica. Quando eu reiniciar o computador esta pasta problemática está acessível novamente. Quando faço logoff antes de dormir, a pasta fica acessível após o despertar. Se eu tentar acessar a pasta usando o FQDN do servidor ou o IP do servidor, ele também estará acessível. Como uma solução temporária, mapeei a pasta para uma unidade de rede usando o FQDN e ela está funcionando bem, mas é inconveniente, pois todas as outras pastas podem ser acessadas no servidor.
Para resumir:
-
\server\problematicshare não funciona mais após o reinício (o servidor Samba vê meu cliente se conectar e, em seguida, desconecta alguns segundos depois de receber a mensagem de erro acima)
-
\server\othershare funciona depois do currículo
-
\fqdn.of.server\problematicshare sempre funciona
-
\ip.of.server\problematicshare sempre funciona
- assim que o problema se manifesta, não consigo mais reiniciar o serviço "Estação de trabalho" (ele não está respondendo)
- reiniciar o serviço "Navegador de computadores" não tem efeito aparente
- o log de eventos não contém nada que pareça relevante
- "servidor de ping" funciona
Link para o despejo de pacotes: link
Este rastreamento de pacote foi obtido no cliente, usando o wireshark, logo após o reinício da suspensão.
Explicação:
- 192.168.1.110 é meu cliente
- 192.168.3.255 é o endereço de transmissão local (esta é uma rede / 22)
- 192.168.0.58 é o controlador de domínio do Samba e também o servidor que compartilha o compartilhamento problemático
- 192.168.1.254 é o servidor DNS
O rastreamento de pacotes foi pós-processado (todos os endereços IP foram alterados substituindo o prefixo; nomes de domínio, servidor e cliente foram substituídos por strings diferentes do mesmo tamanho).
Você notará que o cliente tenta resolver "SERVERNAM". no DNS (ou seja, sem qualificar o nome do servidor), e isso resulta em nxdomain.
É plausível que, se essa pesquisa fosse bem-sucedida, a conexão com o compartilhamento funcionaria.
No entanto, "SERVERNAM" deve ser resolvido via WINS; também, o que causa a mudança de comportamento ao suspender? A mesma pesquisa de DNS falha da mesma maneira antes da suspensão.
Existem também algumas mensagens de log do samba que são relevantes e que serão intercaladas no rastreamento de pacotes nos pontos apropriados.
[2014/08/28 09:54:56.541088, 0] rpc_server/srv_pipe.c:500(pipe_schannel_auth_bind) pipe_schannel_auth_bind: Attempt to bind using schannel without successful serverauth2
[2014/08/28 09:54:56.661321, 0] rpc_server/netlogon/srv_netlog_nt.c:976(_netr_ServerAuthenticate3) _netr_ServerAuthenticate3: netlogon_creds_server_check failed. Rejecting auth request from client WORKSTATION--7 machine account WORKSTATION--7$
(Se houvesse um problema com a conta da máquina, seria tão impossível acessar os compartilhamentos usando o fqdn do servidor, então, embora isso possa ser relevante, certamente não é a causa raiz.)