4

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.

To summarize:

  • \\server\problematicshare no 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\othershare works after resume
  • \\fqdn.of.server\problematicshare always works
  • \\ip.of.server\problematicshare always works
  • 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.

Explanation:

  • 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.)

3
  • Is there a way to get a packet dump of the network conversation just after wakeup? Aug 19, 2014 at 13:02
  • The post has been updated, you can find the link to the packet dump in the article. Sep 1, 2014 at 14:27
  • packet dumps shows two way communication 192.168.1.110.138 -> 192.168.0.58.138 and 192.168.0.58.138 -> 192.168.1.110.138 so it seems even if DNS is failing connections are still accomplished through WINs or broadcasting. I would post the smb.log and nmb.log files to see if they have any hints.
    – Kilo
    Jan 12, 2015 at 21:13

1 Answer 1

0

Sleeping is a bad thing for a networking connection of this type. The Linux box can't tell if you went to sleep, or dropped from the connection. 900 seconds of silence and your connection is intentionally closed, and you have to reinstantiate a new one. You will need some kind of keepalive to maintain connectivity. Your "resume connection" will try reopening the pre-existing connection, and has no skills when it comes to invoking a new one. This is why you have to get the service to restart a connection. Logging out, logging in, should start a new connection.

Are they both on the same logical DNS subdomain?
Do they both have search domain information set up for that subdomain?

Secondly, I am suspecting your samba configuration (on the Linux host) is expecting the full name, even though your server is connecting to the correct host.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .