Share via

The network path was not found when mapping WebDAV drive

Question

Wednesday, February 14, 2018 10:29 PM

Hello,

I am not able to map a drive letter to a WebDAV folder under Windows 10. The WebDAV server is provided by a third party on the Internet. The folder name is the same as the username for logging in to the server, so the URL for the WebDAV folder looks like this:

https://drive.webdav.com/[email protected]/

I can log in through a web browser under Windows 7 and Windows 10.

Under Windows 7 I can map the WebDAV folder to a drive letter with de following command:

> net use z: \\drive.webdav.com@SSL\[email protected] /user:[email protected]

After submitting the password under Windows 10 this command results in: "System error 53. The network path was not found."

I have also tried the PowerShell equivalent:

> New-PSDrive -Name Z -PSProvider FileSystem -Root \\drive.webdav.com@SSL\[email protected] -Credential [email protected]

This also prompts for a password and then results in: "The network path was not found."

I checked the WebDAV capabilities of the server with the following PowerShell command: 

> (Invoke-WebRequest https://drive.webdav.com/[email protected]/ -Credential [email protected] -Method Options).Headers.DAV
1,2,<http://apache.org/dav/propset/fs/1>

I used net use and New-PSDrive commands in combination with URL in stead of UNC notation. This lead to different errors. This was to be expected because I understood that one should use these commands in combination with UNC format.

I also tried to replace the server name with the IP address, but this did not solve the problem.

I read that this can be a symptom of the WebClient service not running. I started up 'services.msc' and found that the WebClient was running. To make sure it is always running I changed it from starting up manually to automatically. Also this did not solve the problem.

I read the questions Unable to map WebDAV over SSL and Windows webDAV client does not support TLS 1.2. It says the early versions of Windows 10 were not supporting TLS 1.2. My Windows 10 is updated to the recent version 1709, so I did not expect this to be a problem. I checked the TLS 1.2 conversation with Wireshark while submitting the above New-PSDrive command:

client > server TLSv1.2 255  Client Hello
server > client TLSv1.2 1514 Server Hello
server > client TLSv1.2 484  Certificate, Server Key Exchange, Server Hello Done
client > server TLSv1.2 236  Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
server > client TLSv1.2 60   Change Cipher Spec
server > client TLSv1.2 155  Encrypted Handshake Message
client > server TLSv1.2 395  Application Data
server > client TLSv1.2 667  Application Data
client > server TLSv1.2 139  Encrypted Alert

From reading the questions I gather that it was not possible to complete the handshake. In this case the handshake is successful. At the end there is an encrypted alert 21. It means that the client could not decrypt a received message. However I repeated this on the Windows 7 machine and the same package appeared. The only difference is that there are many moer Application Data packages between te handshake and the Encrypted Alert package. But that could be explained by the fact that there the network path is available followed by exchange of more network packages.

Who has an idea what the cause is of this problem and how it can be resolved?

Cheers,

Henk

All replies (10)

Thursday, February 15, 2018 8:54 AM

Hi,

There are 3 steps you need to try to check this issue:

1.

1. Run PowerShell as Administrator

2. Set-SmbClientConfiguration -RequireSecuritySignature 1

Answer Y when prompted to confirm the modification.

3. Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" RequireSecureNegotiate -Value 0 -Force

2.

Control Panel / Programs and Features / Turn Windows Features On or Off and make sure SMB 1.0/CIFS File Sharing Support is ticked

3. Change the network provider order:

Locate this registry key: HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order

Changed the value looking setting: LanmanWorkstation,RDPNP,webclient

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

Thursday, February 15, 2018 9:29 PM

Hi Kate Li,

Thank you for your answer.

I carried out all three steps but unfortunately this did not solve the problem.

I checked all steps and I noticed that the setting RequireSecureNegotiate does not show in the registry.

Any other suggestions?

Cheers,

Henk

Friday, February 16, 2018 9:21 AM

Try to add the item under registry key:

HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

RequireSecureNegotiate REG_DWORD 0

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

Saturday, February 17, 2018 1:55 PM

Hi Kate Li,

Thank you for your answer again.

I tried to add "RequireSecureNegotiate REG_DWORD 0" to the above key with the registry editor. It disappears after refreshing. I have seen this kind of behaviour once before on a corporate machines where a policy was applied. But this is my own private machine.

I googled for RequireSecureNegotiate and on this blog post I found that disabling it was a workaround for Window 8.1 which does not work for Windows 10. It offers the same Windows 10 solution as you doe: the command "Set-SmbClientConfiguration -RequireSecuritySignature 1".

Do you have any other suggestions?

Cheers,

Henk

Monday, February 19, 2018 6:49 AM

Hi,

Would you please consult with third party provider support to see if there is any compatible issue on WebDAV with Windows 10? Sometimes it could be the issue.

In addition, since your mean error appear to not received the decrypted package, I recommends you to uncheck TLS1.2 in IE for testing.

For further troubleshooting, please upload the network trace onto OneDrive or other network drive, then share the link here for our research.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

Wednesday, February 21, 2018 10:23 PM

Hi Kate Li,

It will take some time to get an answer from my provider.

I can successfully access the WebDAV site with IE. So what use does it have to uncheck TLS1.2? Or will this also affect mapping a WebDAV drive from the command prompt?

I have found a Message Analyzer guide for tracking messages before they are encrypted. Could that be useful?

What is the relation between WebDAV and SMB secure negotiation? If I google for the combination of these terms I hardly find any hits. They also use different ports.

Cheers,

Henk

Friday, March 2, 2018 9:22 PM

Hi Kate Li,

I have consulted my provider and they are not aware of any compatibility issue between their WebDAV server and Windows 10.

I have unchecked TLS 1.2 in IE, but giving the net use command TLS 1.2 is still used for establishing the connection to the WebDAV server.

With Wireshark I have captured a network trace in this file (link removed). I have tried Microsoft Message Analyzer, but did not get it to work yet.

Then I discovered I can map the root of the server as a network drive with the following command:

> net use z: \\drive.webdav.com@SSL\DavWWWRoot /user:[email protected]

However the z: drive is an empty directory and I am not allowed to add files. I do not have access to my directories and files elsewhere on the server. So the net use command under Windows 10 can make a connection on the server, but apparently it cannot find the path "[email protected]". In web browsers and with the net use command under Windows 7 there is no problem finding this path.

Cheers,

Henk

Tuesday, March 6, 2018 8:54 AM

Hi, 

What's the SMB version the Webdave support?

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

Wednesday, March 7, 2018 1:10 AM

Hi Kate Li,

Thank you for helping.

I do not understand your question. As far as I can tell WebDAV and SMB are 2 different protocols. On the WebDAV Wikipedia page SMB is presented as an alternative to WebDAV for accessing and managing files and folders remotely on a suitable file server from a Windows machine.

If I filter for smb in Wireshark, I only find frames related to Windows machines in the local area network, in Windows 7 as well as in Windows 10.

Cheers,

Henk van den Akker

Friday, October 5, 2018 10:58 AM

Henk,

I am experiencing the same issue. Have you found a solution?