The Folder You Entered Does Not Appear to Be Valid

The dialog, verbatim

The folder you entered does not appear to be valid. Please choose another.

You typed a WebDAV URL into Map Network Drive, Windows thought about it, and refused. No error code, no hint about which part it disliked. The same URL opens in a browser; another WebDAV client connects to it.

Windows produces this message before it gets far enough to have an opinion about your password. It means one of two things: the redirector could not have a WebDAV conversation with that URL, or it could not start the conversation at all. Five causes cover nearly every case, and one command tells you which half you are in.

Step 1: the check that saves the afternoon

Ask the server what it is, the same way the redirector does. Its first request is an OPTIONS to the path you gave it.

curl.exe -i -X OPTIONS -u alice https://dav.example.com/

You are looking for one header in the response. RFC 4918, the WebDAV specification, is unambiguous about it: "All DAV-compliant resources MUST return the DAV header with compliance-class '1' on all OPTIONS responses." So a well-behaved server answers with something like DAV: 1, 2, 3, plus an Allow header listing PROPFIND.

If there is no DAV header, stop configuring Windows. Either that path is not the WebDAV root — the same specification says an OPTIONS request to non-WebDAV resources, including /, "SHOULD NOT advertise WebDAV support" — or the server has WebDAV switched off. Nextcloud, for instance, publishes it at /remote.php/dav/files/<user>, not at the site root.

If the header is there, the server is fine and the remaining causes are all on your machine.

Step 2: start the WebClient service

Every mapped WebDAV drive on Windows is handled by a service called WebClient, and Microsoft's deprecated-features list states plainly: "The Webclient (WebDAV) service is deprecated. The Webclient service isn't started by default in Windows." On a clean Windows 11 machine this is the most common single cause.

Get-Service WebClient | Format-List Name, Status, StartType
Set-Service -Name WebClient -StartupType Automatic
Start-Service -Name WebClient

Then wait a moment before retrying. The redirector keeps a list of hosts it has decided are not WebDAV servers, and ServerNotFoundCacheLifeTimeInSec defaults to 60 decimal seconds; while a host is on that list, Microsoft's documentation says "a fail is returned immediately without attempting to contact the server". Fix something, retry within the minute, and you will be shown a cached refusal.

On Windows Server the redirector is not installed at all until you add the Desktop Experience feature; on desktop Windows it ships in the box.

Step 3: allow Basic credentials over http://

If the endpoint is http:// and authenticates with Basic, Windows refuses before prompting. The switch is a DWORD called BasicAuthLevel under the WebClient parameters key. Microsoft documents three values: 0 disables Basic authentication, 1 enables it "for SSL web sites only", 2 for "SSL and non-SSL web sites". The default is 1.

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 not optional — Microsoft's note on that registry key says the Web Client has to be restarted or the computer rebooted after changing any of these values. And understand the trade: the documentation calls Basic authentication over an unencrypted connection "strongly discouraged", because the credentials go over the wire in clear text. Sensible for 127.0.0.1, defensible on a LAN you own, wrong on the open internet.

Step 4: write the URL the way the redirector wants it

The wizard wants a complete URL, including scheme and any non-standard port: http://dav.example.com:8080/remote.php/dav/files/alice. A bare host name sends Windows down the SMB path, which will never find a WebDAV server.

The command line is more forgiving to debug, because it returns a numbered error instead of a sentence. Microsoft's redirector walkthrough uses the plain URL form, NET USE * http://www.example.com, and the UNC form is documented as \\server[@SSL][@port][\path], where @SSL requests HTTPS and @port is required for anything other than 80 and 443. DavWWWRoot addresses the root of the WebDAV server:

net use Z: \\dav.example.com@SSL\DavWWWRoot\files /user:alice *
net use Y: http://dav.example.com:8080/remote.php/dav/files/alice /user:alice *

If that returns System error 67, you are in the same cause list from the other direction: see net use error 67. If Explorer later reports 0x80070043, that is the same Win32 error wrapped as an HRESULT — error 0x80070043 covers it.

Step 5: Microsoft's own documented cause

There is a genuine parsing bug behind some of these refusals, and Microsoft describes it in a support article dedicated to this exact message. The cause, in their words: "The Windows Web Client service incorrectly assumes that all XML tags from WebDAV servers contain the namespace prefix 'DAV.' However, there are some scenarios in which this assumption is incorrect."

In other words, a server whose PROPFIND response is valid XML but declares the DAV: namespace differently can be rejected out of hand. Microsoft's answer was a hotfix replacing Webclnt.dll on Windows 7 and Windows Server 2008 R2. If you are on a current Windows and a modern server, this is rarely your cause — but it is the reason no amount of credential-fiddling helps when it is.

Two neighbouring causes worth eliminating while you are here: a proxy that intercepts the request (the redirector reports System error 224 and asks you to add the site to Trusted Sites), and stale credentials replayed from Credential Manager. Delete every entry for that host under Windows Credentials, run net use Z: /delete, and try again.

Mapping a local WebDAV server instead

Every rule above still applies when the server is on your own machine, because Windows does not care that the address is a loopback one.

AnyStorage (v0.2.24; macOS 11+, Windows 10+, Ubuntu 20.04+) runs a built-in WebDAV server at http://127.0.0.1:3211, and each storage connection open in the app appears as a folder under that root — an S3 bucket, Cloudflare R2, MinIO, Backblaze B2 or an SFTP host reached through one drive letter, with no filesystem driver to install. Because the endpoint is HTTP with Basic authentication, BasicAuthLevel must be 2 before Explorer will talk to it, and WebClient must be running. The free tier allows two connections.

Next steps

• The numbered version of this failure: WebDAV error 0x80070043 and net use error 67
• Everything else that breaks a Windows mapping: Windows cannot connect to WebDAV
• What changed in Windows 11: WebDAV not working on Windows 11