The other day I was called to investigate a problem where a user could no longer mount a share. The client was running Windows 7. The user got the somewhat obscure message “System error 58 occurred”.
The usual search engines would give silly recommendations like “turn off your anti-virus”. Using Wireshark and knowing a bit about the SMB protocol would quickly deliver a much more reasonable solution.
Refresher: SMB connection set up
Client and server will exchange several messages when a network drive is mapped:
Please note the following events, each coming as a request/response pair.:
- Negotiate Protocol
- Session Setup
- Tree Connect
The Negotiate Protocol phase is used to identify the highest common SMB version shared by client and server. The Session Setup phase is used to authenticate the client. The trace shows an NTLM authentication, which takes 4 packets. In packet 39 the server presents a challenge which the client uses in packet 40 to formulate a response. The Tree Connect would specify the share name.
The faulty connection
A trace file taken from the failing connection shows that client and server will not get beyond the Negotiate Protocol phase. The client aborts the TCP connection with a RESET.
For a root cause analysis, we need to find out if something is wrong with the client or with the server. There are only two packets to look at. Let’s start with the Negotiate Protocol Request:
That’s very odd: The workstation is offering the SMB dialect “NotSmb”. The usual protocol mix offered by Windows 7 would be 6 SMB v1 dialects plus SMB 2:
For the failed connection we don’t get an error code. Still, we see what’s happening by looking at the answer in packet 12:
Clearly, the server did not like the SMB dialects offered by the client. The operation fails because client and server don’t support a common SMB dialect.
Digging into the client
A look at the registry confirmed my suspicions: Someone had turned off SMB v1 on the client. This is done by disabling the driver MrxSmb10 and adjusting the dependencies for the LanmanWorkstation Service. The whole process is described in great detail in an excellent article on Microsoft’s Website:
Please note that the configuration for the MrxSmb10 driver and the LanmanWorkstation service can be found under the registry key HKLM\SYSTEM\CurrentControlSet\Services.
Clearly, the workstation administrator was paying attention to Microsoft’s recommendation and had turned off SMB v1. Unfortunately, the server would only support SMB v1, which causes the connection to fail.
On first impulse one might condemn the workstation administrator for disabling a widely deployed protocol. Watch the wording: “Widely deployed”. Hopefully not widely used: SMB v1 is only required to communicate with Windows XP / Server 2003 and older systems. Or Samba v3 and older, if you use Linux. These are legacy systems and should be migrated to a newer OS or turned off as soon as possible. SMBv1 is a security risk and should be disabled everywhere.
In this case the server was running a more recent version of Samba. Instead of going back SMB v1 we tweaked the server to enable SMB v2. Case closed.