My Win7 client has a connection to a Linux server and its shared folders. The problem occurs when the computer wakes up after a sleep and then one of the shared folders is not accessible. I receive the following message: Error code: 80070035, The network path was not found. I have problem with one specific folder only. When I restart the computer this problematic folder is accessible again. When I log off before sleep the folder is accessible after wakeup. If I try to access the folder by using the FQDN of the server or the server IP it is also accessible. As a temporary solution I mapped the folder to a network drive using the FQDN and it's working fine but it's inconvenient since every other folder is accessible on the server.
\\server\problematicshareno longer works after resume (the Samba server sees my client connect, then disconnects a few seconds later while I receive the above error message)
\\server\othershareworks after resume
- once the problem manifests, I'm no longer able to restart the "Workstation" service (it is not responding)
- restarting the "Computer Browser" service has no apparent effect
- the event log doesn't contain anything that seems relevant
- "ping server" works
Link to packet dump: http://pastebin.ca/2836628
This packet trace was obtained on the client, using wireshark, right after resume from suspend.
- 192.168.1.110 is my client
- 192.168.3.255 is the local broadcast address (this is a /22 network)
- 192.168.0.58 is the Samba domain controller and also the server that shares the problematic share
- 192.168.1.254 is the DNS server
The packet trace has been post-processed (all IP addresses have been changed by replacing the prefix; domain, server and client names have been replaced with different strings of the same length).
You'll note that the client tries to resolve "SERVERNAM." in DNS (i.e. without qualifying the name of the server), and that this results in nxdomain. It is plausible that if this lookup were to succeed, the connection to the share would work. However, "SERVERNAM" should be resolvable via WINS; also, what causes the change in behaviour when suspending? The same DNS lookup fails the same way before the suspend.
There are also some samba log messages that are relevant and that will be interspersed in the packet trace at the appropriate points.
[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$
(If there were a problem with the machine account as such, it would be just as impossible to access the shares using the fqdn of the server, so, while this may be relevant it's certainly not the root cause.)