Troubleshooting WebDAV: The Classic Failures

WebDAV problems have a reputation for vagueness that they largely deserve — at the surface. The operating-system clients report failures in error messages that name neither the cause nor the layer: "The network path was not found." "There was a problem connecting to the server." An error code in hexadecimal. Users translate these as "the drive is broken," and the actual fault — a stopped service, a proxy eating a method, a lock left behind by a crashed laptop — stays hidden.

Underneath the vague surface, though, WebDAV is one of the most diagnosable protocols you will ever troubleshoot, because every operation is an HTTP request with a numeric status code, and you can replay any of them by hand. This guide — part of our WebDAV series — gives you the isolation method first, then the six failure families that account for nearly every ticket, and finally a symptom-to-fix reference table built for mid-incident scanning. It assumes you know the protocol basics from how WebDAV extends HTTP; everything else is explained as we go.

The Method: Take the OS Client Out of the Loop

Every WebDAV interaction crosses four layers: the application, the OS WebDAV client, the network path (with whatever proxies and inspection devices live on it), and the server. The OS client is the least transparent of the four — so the first move in any WebDAV investigation is to bypass it and speak HTTP directly with curl, which exists on every modern platform including Windows. This one technique splits the problem space in half immediately: if curl succeeds where the mount fails, the fault is in the OS client or its settings; if curl fails the same way, the fault is in the network path or the server, and the status code usually names it.

The probe sequence, in escalating order — run it from the affected user's machine or network, because running it from somewhere healthy tests the wrong path:

# 1. Is the server there, and does it speak WebDAV at this path?
curl -si -u alex -X OPTIONS https://files.example.com/dav/projects/ | grep -iE "^(HTTP|Allow|DAV)"

# 2. Can we list the folder?
curl -s -u alex -X PROPFIND -H "Depth: 1" https://files.example.com/dav/projects/ | head -30

# 3. Can we write, and can we read it back?
echo "probe" > probe.txt
curl -si -u alex -T probe.txt https://files.example.com/dav/projects/probe.txt | head -1
curl -si -u alex https://files.example.com/dav/projects/probe.txt | head -1

# 4. Clean up
curl -si -u alex -X DELETE https://files.example.com/dav/projects/probe.txt | head -1

While the probes run, watch the server's access log if you have it. Two questions, answered in seconds: did the request arrive, and what status did the server send? A request that never appears in the log died in the network path. A request logged with a 4xx or 5xx is the server telling you exactly what it objected to. That correlation — client view against server log — resolves most WebDAV mysteries before any deeper tooling comes out.

A pocket dictionary for the codes you will meet: 401 means authenticate (or your credentials were refused), 403 means authenticated but not allowed, 404 means the path is wrong, 405 or 501 means something refused the method itself — a strong hint of a middlebox — 413 means the upload exceeded a size cap, 423 means locked, 507 means the server is out of allotted storage, and 207 is WebDAV's "answers inside" envelope, success-shaped but worth opening when results look partial.

Family 1: Mount and Connection Failures

The share will not attach at all. The usual suspects, in the order they occur in the wild:

• The Windows WebClient service is not running. Windows' entire WebDAV capability lives in one service, disabled by default on server editions. Every mapping attempt fails with "The network path was not found." Check with sc query webclient, start it, set it to automatic. This is the single most common Windows-side cause.
• Basic authentication over plain HTTP. Windows refuses to send passwords over unencrypted connections by default, so an http:// URL fails with an access-denied error no correct password will fix. The right cure is TLS on the server — see securing a WebDAV endpoint — not loosening the client.
• The URL is wrong in a quiet way. DAV endpoints are usually a specific path, and clients differ in whether a missing trailing slash or a wrong parent path shows as 404, 401, or a generic failure. Probe #1 above settles what the server thinks of your URL.
• The TLS certificate does not check out. An expired certificate, a hostname mismatch, or — the sneaky one — a missing intermediate certificate that browsers silently tolerate but stricter OS clients do not. curl -v shows the certificate conversation; a chain that only fails on some clients is the classic signature of a missing intermediate.

Family 2: The Read-Only Mystery

The mount succeeds; writing fails. Two distinct causes produce it, and the OPTIONS probe distinguishes them in one line.

Cause A: the server lacks class 2. Several OS clients — the macOS Finder prominently, and Windows in some configurations — require the server to advertise lock support (compliance class 2) before permitting writes, reasoning that editing without locks risks silent lost updates. Against a class-1-only server they mount read-only without saying why. If your OPTIONS probe shows DAV: 1 with no 2, that is the whole story: enable locking on the server if it offers it, or accept (even embrace) the read-only behavior.

Cause B: the server is denying write methods. If OPTIONS shows class 2 but a curl PUT returns 403 Forbidden, the server is configured to refuse writes — an authorization rule limiting PUT and friends to certain users, often deliberately (a hardening pass like the one in our securing guide does exactly this). The access log will show the 403 with the username; the fix is an entry on the allowed-writers list, or the knowledge that the restriction is intentional.

Family 3: Credential Chaos

Because HTTP is stateless, WebDAV clients authenticate every request and therefore cache credentials aggressively — Windows in Credential Manager, macOS in the Keychain, davfs2 in its secrets file, desktop Linux in the keyring. The caches produce two recurring tickets:

The post-password-change lockout. A user changes their password; within minutes their account locks. A mount somewhere — often on a second machine, or a mapping set to reconnect at sign-in — is replaying the old password on every request, and three failures trip the lockout policy. The fix is procedural: when a WebDAV password changes, clear the stored entry in every credential store on every machine that mounts the share, then reconnect fresh. Hunting the offending machine is easier from the server's access log: the failing requests name their source address.

The endless password prompt. The client asks, the user types correctly, the prompt returns. Three causes dominate: a stale cached credential that the client silently prefers to the typed one (clear the store); an authentication-scheme mismatch, where the server offers only a scheme this client cannot speak — a server offering only an integrated scheme to a non-domain machine is the textbook case (align the schemes; Basic-over-TLS is the compatibility baseline); or the URL actually resolving somewhere unexpected — a proxy's login, not your server's (see the next family).

Family 4: Large Files and Timeouts

Small files work; big ones fail. WebDAV's whole-file transfer model — a PUT is the entire file or nothing, with no standard resume — means every size-related limit in the path becomes a cliff edge. Four cliffs, in the order to check them:

1. The Windows client's own ceiling. Downloads over the WebClient's limit — about 50 MB by default — fail with error 0x800700DF, "The file size exceeds the limit allowed." Raise FileSizeLimitInBytes in the WebClient service's registry parameters and restart the service; note the absolute ceiling of roughly 4 GB. Full registry details are in the mounting guide.
2. Server-side body limits. Web servers cap request body sizes, and an upload over the cap fails with 413 — often instantly, which is the tell (a timeout takes minutes; a policy refusal is immediate).
3. Middlebox timers. When large uploads die after a suspiciously consistent interval — always around sixty seconds, always around five minutes — some proxy, gateway, or load balancer's timeout is expiring mid-transfer, frequently surfacing as 504. Consistency of the failure time is the fingerprint: real network trouble fails randomly; timers fail punctually.
4. davfs2's cache disk. The Linux davfs2 client stages whole files in a local cache, so a "network" write error can actually mean the local cache volume is full.

You can raise each limit deliberately — and for routine multi-gigabyte payloads, the honest fix is moving that flow to a protocol with resume, which is SFTP's territory.

Family 5: Proxies and Inspection Middleboxes

WebDAV rides HTTP, which means it inherits every device that meddles with HTTP — and some of those devices have never heard of the extended methods. This family's signature is geographic: it works from home and fails from the office, or works on the guest network and fails on the corporate one, because the difference between those paths is the middlebox.

• Method-filtering proxies and web application firewalls. Built with GET and POST in mind, they reject PROPFIND or MOVE with 405 or 501 — or worse, drop them silently. The server log shows the request never arriving. Fix: allow the extended methods for the DAV hostname, or bypass the proxy for it.
• Caching proxies. A cache that stores DAV responses serves stale listings: a user uploads a file, and colleagues cannot see it for minutes. Disable caching for the DAV host, and serve it with cache-suppressing headers.
• TLS inspection appliances. Devices that decrypt and re-encrypt HTTPS sometimes mishandle large or streamed request bodies, breaking big PUTs that work everywhere else — and their re-signed certificates can trip stricter DAV clients. If uploads fail only behind the inspection device, you have found the suspect; exempting the DAV host from inspection is the usual settlement.
• Proxy auto-detection delays. The Windows client checks for automatic proxy configuration before requests; on networks where that lookup times out instead of answering, every operation drags. Explorer crawls while curl (which skips auto-detection) flies — that contrast is the diagnostic. Give machines a definite proxy answer, configured or explicitly none.

Family 6: Lock Trouble

WebDAV's locking model — a client takes a lock, holds a token, and must present it for writes — fails in one characteristic way: the orphaned lock. A client crashes, reboots, or loses its network mid-edit. The token dies with the client's memory; the lock lives on server-side, refusing everyone's writes with 423 Locked until its timeout expires. Users report it as "the file says it's in use, but nobody has it open," and they are exactly right.

You can interrogate a lock directly — the lockdiscovery property reports the holder, scope, and remaining timeout:

curl -s -u alex -X PROPFIND -H "Depth: 0" \
  -H "Content-Type: application/xml" \
  --data '<?xml version="1.0"?>
<propfind xmlns="DAV:"><prop><lockdiscovery/></prop></propfind>' \
  https://files.example.com/dav/projects/report.docx

An empty lockdiscovery means no lock — look elsewhere (some applications show "in use" for their own reasons). A populated one names the owner and timeout: you can wait out short timeouts, or clear the lock server-side — most DAV servers give administrators a way to list and remove active locks. Two prevention notes: favor modest lock timeouts on the server, so orphans clear themselves in minutes rather than days; and expect mixed-client folders to produce near-miss reports like "file changed on server" — that is what it looks like when a locking client and a non-locking client share a document, since locks only bind clients that use them.

The Reference Table: Symptom, Cause, Fix

The whole guide condensed for mid-incident scanning:

When to Stop Fighting

A closing word of triage honesty. If the same endpoint generates the same family of tickets month after month — size-limit complaints, credential lockouts, proxy fights across a fleet of client platforms you cannot standardize — the problem may not be a bug to fix but a mismatch between the tool and the job. Two structural exits cover most cases: users who only ever upload and download are better served by a browser-based HTTPS portal, which has no client quirks because the client is a browser — a role a file transfer server like Sysax Multi Server fills with its HTTPS support; and unattended flows that scripts push through a mounted drive are better rebuilt as scheduled transfer jobs over a protocol with resume and retry semantics. The decision framework lives in WebDAV vs SFTP vs SMB.

For everything else, the method holds: probe with curl, correlate with the server log, and match the symptom to its family. WebDAV rewards troubleshooters who speak a little HTTP — which, after this series, you do.

Frequently Asked Questions