Situation: When the client tries to map a file share, he receives the following errors:
•System error 53 has occurred. The network path was not found.
•System error 67 has occurred. The network name cannot be found.
•System error 87 has occurred. The parameter is incorrect.
Cause 1: Unencrypted communication channel
Windows 8, Windows Server 2012, and later versions of each system negotiate requests that include SMB 3.0, which supports encryption. If the communication channel isn’t encrypted and if the connection attempt isn’t made from the same datacenter where the Azure file shares reside, you may receive above errors.
Resolution: 1. make sure the communication channel is encrypted. Make sure your client OS needs support SMB 3.0, for example use Windows 8, Windows 10, Windows Server 2012.
2. Put the client in the same LAN.
3. Make sure the client computer network is domain or private. If it is public network, we may have a problem to access LAN shared drive.
4. It is not recommended, but you can try to enable SMB 1.0.
Cause 2: Port 445 is blocked
Resolution: you can use Portqry to query the TCP:445 endpoint. If the TCP:445 endpoint is displayed as filtered, the TCP port is blocked. Here is an example query:
c:\PortQry.exe -n [storage account name].file.core.windows.net -p TCP -e 445
If TCP port 445 is blocked by a rule along the network path, you will see the following output:
TCP port 445 (microsoft-ds service): FILTERED
Resolution: Work with your IT department to open port 445 outbound
Cause 3: NTLMv1 is enabled
System error 53 or system error 87 can occur if NTLMv1 communication is enabled on the client. Windows new version Files supports only NTLMv2 authentication.
Resolution: To determine whether this is the cause of the error, verify that the following registry subkey is set to a value of 3:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel
Resolution: Revert the LmCompatibilityLevel value to the default value of 3 in the following registry subkey:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa