WebDAV Error 0x80070043: The Network Name Cannot Be Found

The code, and what it really says

You paste a WebDAV URL into Map network drive, Windows thinks about it for a few seconds, and then:

Windows cannot access https://dav.example.com
Error code: 0x80070043
The network name cannot be found.

The URL opens fine in a browser. Another WebDAV client connects to it without complaint. Explorer still says the network name cannot be found.

It is not a DNS failure, and the server is usually innocent. 0x80070043 is the HRESULT form of Win32 error 67, which Microsoft's error-code reference lists as ERROR_BAD_NET_NAME, "The network name cannot be found." The 0x8007 prefix means "a Win32 error, wrapped"; 0x43 is 67 in hex. The command line reports the identical failure as System error 67 has occurred, so net use error 67 covers the same causes from the other direction.

Windows uses that one message for every early WebDAV failure. Once you know the four things hiding behind it, the diagnosis takes two minutes.

Microsoft's WebDAV redirector documentation lists six conditions for "System error 67". The two left out above are IIS not running on the target and a missing proxy-bypass entry for an FQDN site using Windows authentication.

1. Start WebClient, the service nobody starts

Every mapped WebDAV drive on Windows is handled by a service called WebClient. Microsoft deprecated it in November 2023, and the deprecation notice says plainly that "the Webclient service isn't started by default in Windows." A clean Windows 11 install therefore fails at WebDAV mapping until you turn the service on.

Check and start it in PowerShell, as administrator:

Get-Service WebClient | Select-Object Status, StartType
Set-Service -Name WebClient -StartupType Automatic
Start-Service -Name WebClient

Or from an elevated command prompt:

sc.exe config WebClient start= auto
sc.exe start WebClient

The space after start= is not a typo. Microsoft's sc.exe config reference states that a space is required between an option and its value, and that omitting it makes the operation fail, even though forum answers copy start=auto around constantly.

One more trap: WebClient caches hosts it has decided are not WebDAV servers, and ServerNotFoundCacheLifeTimeInSec defaults to 60 seconds. If you fixed something and retried at once, you may have been handed a cached refusal. Wait a minute, or restart the service.

2. Let Windows send Basic credentials to an http:// URL

This is the cause that eats afternoons, because Windows fails without ever prompting for a password.

WebClient reads a registry value called BasicAuthLevel. Microsoft documents three values: 0 disables Basic authentication, 1 enables it for SSL sites only, and 2 enables it for both SSL and non-SSL sites. The default is 1. Point the redirector at an http:// endpoint with Basic auth and it refuses before the first credential exchange, then reports 0x80070043.

From an elevated prompt:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters" /v BasicAuthLevel /t REG_DWORD /d 2 /f
net stop WebClient
net start WebClient

The restart is mandatory: Microsoft's documentation notes that after changing any of these values WebClient has to be restarted or the computer rebooted. People skip it, retry, see the same code, and conclude the fix is folklore.

Be clear-eyed about what level 2 costs: the username and password go over the wire in clear text. That is fine for 127.0.0.1, defensible on a network you control, and wrong across the open internet, where you want an https:// endpoint instead.

3. Write the URL the way the redirector expects

Explorer's wizard wants a full URL, including the scheme and any non-standard port, such as http://dav.example.com:8080/remote.php/dav/files/alice. A bare host name sends it down the SMB path, which never reaches a WebDAV server.

From the command line there are two accepted shapes. The plain URL form appears in Microsoft's redirector walkthrough as NET USE * http://www.example.com. The UNC form is documented with the DavGetHTTPFromUNCPath function as \\server[@SSL][@port][\path], where @SSL requests HTTPS and @port is needed for anything other than 80 and 443:

net use Z: \\dav.example.com@SSL@443\DavWWWRoot\files /user:alice
net use Y: http://127.0.0.1:3211/ /user:anystorage

DavWWWRoot is the keyword that tells the redirector it is addressing the root of a WebDAV server, and Microsoft's own reconnect-troubleshooting article uses exactly this form. Two details from the same documentation matter here: the WebDAV extensions specification records that pre-Vista clients supported port 80 only, and Microsoft states that since Windows 7 Basic credentials cannot be persisted by Credential Manager, so a Basic-auth mapping has to be reconnected rather than restored at logon.

If a stale password is being replayed, clear it first: Control Panel, Credential Manager, Windows Credentials, delete every entry for that host, then run net use Z: /delete.

When the drive maps and then the copies fail

Different error, same afternoon. If the mapping succeeds but any file over about 50 MB dies with 0x800700DF, that is FileSizeLimitInBytes, default 50,000,000 bytes, with a hard 4 GB ceiling: see the Windows WebDAV 50 MB limit.

Mapping a local WebDAV server, such as AnyStorage on 3211

AnyStorage runs a WebDAV server on your own machine. Open Services in the sidebar, switch to the WebDAV tab, press Start, and you get http://127.0.0.1:3211. Every storage connection open in the app appears as a folder under that root, so one mapped drive can cover an S3 bucket, Cloudflare R2, Backblaze B2, MinIO, Google Drive, OneDrive, Dropbox and an SFTP host at once, with no WinFsp driver to install.

Everything above still applies. The endpoint is HTTP and authentication is Basic, always on, so BasicAuthLevel has to be 2 before Explorer will talk to it. Use the credentials from the WebDAV tab: default username anystorage, and a 24-character password generated on first use, so copy it rather than retype it. Two behaviours surprise people. On the free tier the mount is read-only; read-write is a Pro feature. And after an app restart a connection appears under the WebDAV root only once you have opened it in the app, because connections connect lazily.

Next steps

• The command-line form of this failure: net use error 67
• The full checklist when more than one thing is wrong: Windows cannot connect to WebDAV
• Large-file failures after a successful mapping: the Windows WebDAV 50 MB limit