(This has started to get quite lengthy, but hopefully will provide a summary of things to try for anyone else that's bumped into this issue - it's not a simple one-size-fits-all solution by the looks of things; other solutions or avenues of investigation may be found in the answers as well).
I'm having problems getting a reliable share working on an x64 Server 2008 R1 SP1 server.
All works well after a reboot, but after some time (within a day) the shares become unavailable to XP and Server 2003 servers. Interestingly, they remain available to other Server 2008 servers.
On trying to access \\server\share, Server 2003 returns immediately and simply gives me the message "The specified network name is no longer available", XP takes a minute or two to timeout before giving the same message. There doesn't seem to be anything in the event logs indicating a problem.
Doing some googling over the last day or two I've seen the following blamed:
- Bad network drivers (Broadcom [which is what the HP servers we use have] seems to get a few mentions for being flaky) ... I've updated to the latest drivers with no result (see refs 1 and 2)
- Symantec anti-virus ... we're not using it (currently no AV on the server) (see refs 1 and 3)
- Receive window auto-tuning ... I've disabled with
netsh int tcp set global autotuninglevel=disabledandnetsh int tcp set global rss=disabled(see ref 4)
None of these have had an effect. Windows Firewall is currently disabled.
As other Server 2008 boxes (both x32 and x64) can connect, I can only assume that there's some new security configuration that's not quite right - or there's an AD issue that I need to trace, but don't know where to start. Even if anyone doesn't know how to resolve, if someone knows what I need to look for with Wireshark this would be a help.
EDIT ... I've put a Wireshark trace on (filtered by target host only) and what I'm seeing is that the client (Server 2003 in this case) sends an SMB "Negotiate Protocol Request" message to Server 2008, however no "Negotiate Protocol Response" is received from the server. The client retries until it times out. Note however that the server is responding postively to a session request. This is the full sequence of events:
C -> S NBSS Session Request
S -> C NBSS Positive Session Response
C -> S SMB Negotiate Protocol Request
[no response; time passes].
C -> S NBSS Session Request
S -> C NBSS Positive Session Response
C -> S SMB Negotiate Protocol Request
[no response; time passes].
[repeat]
EDIT2... Wiresharking a SMB connection from Server 2008 client shows the the Negotiate Protocol Response being sent, but with SMBv2:
C -> S NBSS Session Request
S -> C NBSS Positive Session Response
C -> S SMB Negotiate Protocol Request
S -> C SMB2 NegotiateProtocol Response
C -> S SMB2 SessionSetup Request
S -> C SMB2 SessionSetup Response
[then the conversation contines, bringing the share back]
I'm going to try disabling SMBv2 on the 2k8 server (as per these instructions on petri.co.il) and see if that helps - should force the server to use SMB1 everywhere then.
EDIT3... I've also found this article on Microsoft Technet Forums ("Windows 2008 Keep disconnecting shares + outlook 2007 keep loos conection to exchange 2007" [sic]), to which others have suggested checking TCP Offload Chimney configuration. At this present moment however having disabled SMB2 (see EDIT2, above) things seem to be okay at the moment - shares have yet to disappear having disabled SMB2 last Friday. A quick google's found someone else (MS Technet forum "File opening issue on a server 2008 share.") who found that disabling SMB2 was also a solution. I'll let this tick over for a couple more days before self-answering and closing this question down.
References...
(1) Microsoft Networking Team - Intermittent file sharing connectivity from various clients to a Windows Server 2008 server
(2) 424help.com - Windows 2008 Server Network Connectivity Problem
(3) Symantec AVForums - MR3 Locks up Server 2008 file shares
(4) Usenet - Server 2008 R2 file share access fails under heavy load (also mirrored on various web forums like techarena, eggheadcafe, etc)
In your capture, add Packet Length to the displayed columns, and sort by that column. Do you have any frames that are larger than a normal ethernet frame? (1514 I think). You should take this capture from the server if possible. Or on a switch port that mirrors the server switch port.
It's been nearly a week since SMB2 was disabled (see EDIT2 in the question), and sharing has been stable since then. For reference, the server is configured with:
I could probably re-enable receive window autotuning, however as this is an active system, that's probably not going to happen quickly: I'm leaving it alone now on that grounds that if it ain't broke, don't fix it.
If anyone else has a similar issue, the solution may be different (see rest of this question) - however disabling SMB2 ultimately was the fix for my situation.
As an aside, a quick google seems to indicate other isses that can be worked around by disabling SMB2, including (the happy snappy short titles are direct from the MSDN KBs):
Hope this all helps someone else :-)
EDIT - May 2014 ... many years later. Microsoft have recently released a KB article Windows stops responding if SMB v1 protocol is used to access shared files that is targeted at Server 2008, which documents that the problem can occur "occurs because of a deadlock in the Mrxsmb10.sys driver.", and a hotfix is provided. The problem hasn't re-materialized here, so I won't be applying - however the detail sounds like the experience I've had above. I'm including it in the answer should it be useful for anyone else.