Mounting Remote Storage as a Drive with WebDAV

The pitch is genuinely attractive: a folder on a server — in another office, another country, another organization — appears on your machine as an ordinary drive. Users double-click files, drag and drop, hit Save, and never learn a new tool. And because WebDAV rides on HTTPS, the whole thing crosses firewalls that would never permit a traditional file share. Every major desktop operating system ships a WebDAV client, so there is nothing to install.

The catch is that those built-in clients are the most quirk-ridden corner of the entire WebDAV ecosystem. Each has file-size ceilings, credential-caching habits, and performance characteristics that surprise people — usually in the middle of a workday, usually with an error message that names none of the actual causes. This guide, part of our WebDAV series, gives you the exact mounting steps for Windows, macOS, and Linux, then the honest briefing on what each client can and cannot do, so you can set expectations before your users set them for you.

What a Mount Actually Is

It helps to know what you are switching on. When you mount a WebDAV share, you are not copying anything and not opening a persistent connection. You are activating a translator: a component of the operating system (Windows calls its one the WebClient service; on other systems it lives in the file manager or a filesystem driver) that sits between ordinary applications and the network. Applications keep making the file calls they have always made — open, read, write, list, rename. The translator converts each one into HTTP requests: a folder listing becomes a PROPFIND, a save becomes a PUT of the whole file, a rename becomes a MOVE. (If those verbs are new to you, start with how WebDAV extends HTTP — this article leans on it constantly.)

The diagram below shows the pipeline hiding behind the drive letter.

That translation is the source of every quirk in this article. Applications and users assume drives are fast, local, and always writable, because real disks are. A WebDAV mount is a remote, stateless, request-per-operation illusion of a disk — and where the illusion thins, the quirks show through.

Before You Mount: A Five-Minute Preflight

Most failed mounts fail for one of four boring reasons. Check them before involving any operating system:

1. The exact URL. WebDAV endpoints are often a specific path, not the server root — https://files.example.com/dav/projects, not https://files.example.com. A wrong path yields errors that look like authentication failures on some clients.
2. HTTPS, not HTTP. Beyond the obvious security reasons, some clients (notably Windows, by default) refuse to send passwords over plain HTTP at all, so an http:// URL can fail even with perfect credentials.
3. Working credentials. Confirm them in a browser first — browsers speak enough WebDAV to trigger the login prompt and usually show a bare file listing.
4. Write support on the server. Several OS clients require the server to advertise locking (compliance class 2) before they permit writes; without it, expect a read-only mount.

A command-line probe with curl settles all four at once, from any platform, before you touch a mount dialog:

# Does the server speak WebDAV here, and does it support locking (class 2)?
curl -i -u alex -X OPTIONS https://files.example.com/dav/projects/
#   look for:  DAV: 1, 2      and   Allow: ... PROPFIND, PUT, LOCK ...

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

If OPTIONS answers with a DAV: header and PROPFIND returns XML, the server side is healthy and anything that fails from here on is client-side. That single fact will save you hours.

Mounting on Windows

Windows' WebDAV client is the WebClient service plus a filesystem driver Microsoft calls the WebDAV Mini-Redirector. The service must be running for any mount to work — on some editions, especially servers, it is disabled by default, and every mapping attempt fails with "The network path was not found" until you start it.

Two ways to mount. Through the interface: File Explorer → right-click "This PC" → "Map network drive," pick a letter, and enter the full HTTPS URL as the folder. Or from a prompt, which is scriptable and shows real errors:

# make sure the WebDAV client service is running
sc query webclient
net start webclient

# map drive W: to the share (prompts for the password)
net use W: "https://files.example.com/dav/projects" /user:alex * /persistent:yes

# verify, and later disconnect
net use
net use W: /delete

Now the limits you need to know about, because Windows enforces both of the classics.

The file-size ceiling

The WebClient service refuses to download files larger than a configured limit — by default about 50 MB (the value is 50,000,000 bytes). Users hit it as error 0x800700DF: "The file size exceeds the limit allowed and cannot be saved." The limit is a registry value you can raise:

Key:    HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Value:  FileSizeLimitInBytes   (DWORD)
        default 50000000 (about 47 MB)
        maximum 4294967295 (about 4 GB)

Value:  BasicAuthLevel         (DWORD)
        1 = Basic authentication over HTTPS only (default)

# apply changes by restarting the service
net stop webclient
net start webclient

Note the maximum: even fully opened up, the Windows client tops out at roughly 4 GB per file. That is a hard ceiling of the client, not the protocol. Anything bigger needs a different client or a different protocol.

The authentication rules

The same registry area's BasicAuthLevel controls a sensible default: Windows will not send Basic authentication (username and password, merely encoded, not encrypted) over unencrypted HTTP. If your server offers Basic over plain HTTP, Windows fails the mount with an access-denied error that no correct password will ever fix. The right response is not to loosen the client — it is to put TLS on the server, which you should be doing anyway; our securing WebDAV article covers that pass. Credentials you save while mapping land in Windows Credential Manager, which becomes important during password changes (more below).

One more Windows habit

If a freshly mapped drive is inexplicably slow — every folder click pausing for several seconds — the usual culprit is not WebDAV at all but the client's proxy discovery. Before requests go out, Windows checks whether the network defines an automatic proxy, and on networks where that lookup times out rather than answering, the delay is paid over and over. It shows up so often against WebDAV mounts that it earns a place in the troubleshooting article's reference table; the short version is to give the machine a definite proxy answer — configured or explicitly none — instead of leaving it searching.

Mounting on macOS

macOS hides its WebDAV client inside the Finder. Go → Connect to Server (Cmd-K), enter the HTTPS URL, authenticate, and the share appears under /Volumes and in the Finder sidebar like any disk. The same mount is available from a terminal:

sudo mkdir -p /Volumes/projects
mount_webdav -i https://files.example.com/dav/projects /Volumes/projects
#  -i prompts interactively for the username and password

# later, unmount
umount /Volumes/projects

The macOS client is competent and generally faster than Windows' at browsing, with two habits worth knowing. First, it litters: the Finder writes .DS_Store files (folder-view settings) and paired ._name files (metadata sidecars, called AppleDouble files) onto the server. They are harmless but confuse Windows and Linux users who see them appear in shared folders. Second, like Windows, the Finder wants lock support: against a server without class 2, the volume typically mounts read-only, with no explanation offered. Saved passwords go to the login Keychain.

Mounting on Linux

Linux gives you two routes with different characters.

davfs2 is a filesystem driver, the closest thing to a true mount: any application can use it, it works headless on servers, and it goes in /etc/fstab. Install the davfs2 package from your distribution, then:

sudo mkdir -p /mnt/projects
sudo mount -t davfs https://files.example.com/dav/projects /mnt/projects
# prompts for username and password

# store credentials instead (file must be chmod 600):
#   /etc/davfs2/secrets
#   https://files.example.com/dav/projects  alex  "the-password"

# optional fstab entry so users can mount it without root:
#   https://files.example.com/dav/projects  /mnt/projects  davfs  user,noauto  0  0

# unmount — this also flushes pending uploads, so let it finish
sudo umount /mnt/projects

davfs2's defining behavior is its write-back cache. Files you save land in a local cache directory first and upload to the server in the background, often only when the file is closed. This makes applications feel fast — and it means a file can look saved while it has not yet reached the server. Pull the network cable, or power off without unmounting, and "saved" work exists only in the local cache until the next mount reconciles it. Scripts that write through davfs2 and then tell another system "the file is there" have built themselves a race condition.

GVfs/gio is the desktop route: in GNOME Files enter davs://files.example.com/dav/projects (note the scheme: davs is WebDAV over HTTPS), or script it with gio mount davs://.... It integrates with the desktop keyring for credentials and is fine for interactive use, but it is a user-session mount — not something for system services or fstab.

Credential Handling: Where Passwords Hide

Because HTTP is stateless, every single WebDAV request must authenticate, so every client caches credentials aggressively: Windows in Credential Manager, macOS in the Keychain, davfs2 in its secrets file, GVfs in the desktop keyring. Day to day this is invisible. On the day a password changes, it becomes the whole story: some cache keeps replaying the old password, and three failed replays trip the account-lockout policy. The user swears they typed the new password — they did, into one prompt, while two other caches kept using the old one.

Make it routine: when a WebDAV password changes, clear the stored entry everywhere it might live (Credential Manager on Windows, Keychain Access on macOS, the secrets file on Linux) before the first reconnect. For unattended mounts, prefer a dedicated service account per system over a human's password, so one person's password change never breaks a machine's mount — the same discipline you would apply to any stored credential.

Performance Expectations, Set Honestly

A WebDAV mount will never feel like a local disk, and it is worth being able to explain why with numbers rather than shrugs. Every file operation is at least one HTTP round trip, so latency, not bandwidth, sets the feel. On a LAN at 1 millisecond, a folder listing (one PROPFIND) is instant. Across a WAN at 80 milliseconds, opening a tree of 25 nested folders costs 25 round trips — two seconds of pure waiting before any file content moves. Browsing feels "sticky" in direct proportion to distance.

Applications amplify this. Office suites save documents the safe way: write a temporary file, then rename it over the original — which over WebDAV becomes a full PUT of the whole document plus a MOVE, plus lock traffic on clients that use it, every time someone presses Save. Reading is friendlier than writing: clients can fetch byte ranges of a file, so jumping into the middle of a large video usually works. Writing has no partial option — any change to a file re-uploads the entire file.

Folder shape matters as much as file size. A directory with 10,000 entries turns each listing into a very large XML response that the server must build and the client must parse — some clients stall visibly, and a few give up. If you control the layout, prefer more folders with fewer entries each; a year/month or project/phase hierarchy keeps every individual PROPFIND cheap. And when you want to know what a mount is really doing, read the web server's access log while you click around: the stream of PROPFIND, GET, PUT, and MOVE lines is the honest account of the traffic your users' drag-and-drop is generating.

Two honest rules of thumb follow. WebDAV mounts are at their best with documents at human scale — files up to a few tens of megabytes, folders of hundreds rather than tens of thousands of entries, users who open and save occasionally. And they are at their worst as bulk pipes: copying thousands of small files through a mount pays the per-request overhead thousands of times, which is why "drag the whole archive folder onto the W: drive" runs for hours where a purpose-built transfer would take minutes.

When Something Other Than a Mount Is the Right Call

A mount is a live window: nothing is stored locally, every open crosses the network, and when the network is gone the files are gone. That is exactly right for some jobs — occasional access to a shared document pool, a scanner dropping files onto a server, light collaborative editing. Other requirements fit it badly, and recognizing them early spares everyone the slow discovery:

• Offline work. If laptops must open files on a train, you want a sync client — a tool that keeps a local copy of the folder and reconciles changes in the background. Local files mean native speed and offline access, at the cost of sync conflicts when two people edit the same file apart.
• Large files, routinely. Multi-gigabyte payloads deserve a transfer protocol with resume support rather than a client with a 4 GB ceiling and all-or-nothing uploads.
• Scheduled, unattended movement. Scripts that copy files through a mounted drive letter inherit every mount fragility: credential caches, timeouts, the davfs2 write-back race. If the actual requirement is "files move from A to B on a schedule, reliably, with retries and logging," that is a transfer job, not a drive — a tool like Sysax FTP Automation does exactly this over SFTP or FTPS, with error handling designed for the 2 a.m. run no one is watching.
• Many users on a LAN. Inside one building, a conventional network share outperforms a WebDAV mount in every dimension; see our network shares vs file transfer series for that boundary.

The mount is the right tool when you need drive semantics across the open internet with zero installed software. The moment the requirement shifts to bulk, offline, or unattended, reach for the matching tool instead — the comparison in WebDAV vs SFTP vs SMB maps the whole territory.

The Short Version

Mounting WebDAV storage is a five-minute job on every major desktop: net use against a running WebClient service on Windows, Connect to Server or mount_webdav on macOS, davfs2 or gio on Linux — always over HTTPS, always after a quick curl preflight of OPTIONS and PROPFIND. The clients differ in temperament: Windows imposes size limits and strict authentication rules, macOS scatters metadata files and insists on lock support for writes, davfs2 caches writes locally and uploads when it pleases. None of this is broken; all of it is the cost of impersonating a disk with stateless web requests.

When a mount misbehaves anyway, work through our troubleshooting guide — most failures are one of a dozen classics. And before exposing any newly mounted endpoint to the internet, give it the hardening pass.

Frequently Asked Questions