Why a drive letter still matters

In an all-cloud world you'd expect the mapped drive to be a relic. It isn't — because a large amount of real business software can only open a path, never a web address: accounting and ERP systems, Access back-ends, CAD and engineering files linked by path, backup jobs, batch scripts, scheduled exports. Give them https://…sharepoint.com/… and they simply can't. Give them X:\Projects\… and they just work. That single fact keeps the drive letter alive. (We lived the whole saga behind this — the developer story is here.)

The methods people try

1 · WebDAV — "Add a network location"

Fragile

The method everyone reaches for first: paste the site URL into Map network drive and let Windows' built-in WebDAV client mount it. In a clean demo it looks perfect. In daily use it's the most confusing one, because it's the method Microsoft has effectively wound down.

  • The session won't stay alive — this is the real problem. The auth cookie lasts only a few hours, after which the drive silently drops or starts prompting again. The built-in client doesn't renew it on its own, so users hit "access denied" in the middle of work several times a day. That, not any single limit, is what makes WebDAV unfit for daily use.
  • It leans on Internet Explorer. The classic mapping flow depends on the old IE engine for authentication — and Microsoft discontinued IE11 access to SharePoint and OneDrive in mid-January 2023. When it breaks, you're asked to re-authenticate in "Internet Explorer mode."

2 · OneDrive sync (with a drive letter on top)

Copies everything

The sync client can put your library in Explorer, and you can even subst a letter onto the synced folder. But this isn't a "no-copy" drive — it mirrors files to the disk, which brings the whole large-library problem back: Microsoft's own guidance is to stay under 300,000 synced items for good performance, first sync on a big library can take the better part of a day, and "processing changes" can last for days. Fine for a small folder; a wall for a terabyte. We hit every part of that wall.

3 · Just use the browser

No path for apps

Perfectly fine for opening a document by hand. Useless for the software that needs a real path — the accounting system, the Access back-end, the CAD file, the backup job. They can't open a web address, and no amount of "just use the browser" changes that.

4 · Dedicated paid "drives" for SharePoint

Breaks the cloud

There are separate paid apps that promise SharePoint and OneDrive as a drive. They take away some of WebDAV's pain — but on the way they break the very thing the cloud is for:

  • They require an Azure app registration. Before a single drive appears — admin consent and a project in the tenant. For a small company without an IT department, that's a stopper.
  • They kill real-time editing. Instead of live co-authoring you get either a hard lock on the file for one person, or version conflicts for several. The best thing the cloud gives you disappears.
  • They overwrite the version history. Every save pushes a whole new copy of the file to the cloud instead of editing the living document — the clean version chain is replaced by a stack of full-file overwrites.
The pattern: WebDAV expires (the session won't stay alive), sync copies everything, the browser can't give a path to apps, and dedicated paid "drives" break co-authoring and version history. None of them gives you all of it at once: a live session, zero copies, a path for apps, and the cloud features preserved.

What actually holds up

Strip the failures into requirements and the answer is specific. A drive letter for SharePoint that survives real work has to:

  • Mount without Internet Explorer — no dependency on a deprecated engine.
  • Keep the session alive — renew authentication silently, so the drive doesn't drop every few hours.
  • Copy nothing to the disk — so a terabyte library and its million files are a non-issue, and there's no 300,000-file ceiling.
  • Preserve co-authoring and version history — the file on the drive has to be the live cloud document, not a copy that overwrites the cloud on every save.
  • Need no Azure app registration — a normal Microsoft 365 sign-in, nothing for an admin to approve.

The drive letter should be a window onto the cloud file — not a copy of it. Get that right and everything SharePoint does well keeps working through X:\.

How OneMount does it

OneMount is the tool we built to meet that list. It mounts SharePoint Online and OneDrive libraries as ordinary Windows drives over WebDAV — but without the Internet Explorer dependency, with the session kept alive in the background, and without copying anything to your disk. Because the file on the drive is the live SharePoint document, Word and Excel open it with real co-authoring, AutoSave and full version history intact — the things the other approaches quietly switch off.

  1. Install — one file, no admin rights.
  2. Sign in — your normal Microsoft 365 account; OneMount finds your sites and libraries itself. No Azure registration, no admin consent, no tenant setup.
  3. Work — the drives are in File Explorer, and every app that wants a path finally gets one. The trial starts automatically.

And for everyday sharing — a right-click menu in File Explorer: right-click a file or folder on the drive to copy the SharePoint web link (for outside people) or the drive path (for colleagues inside), open the file in SharePoint, show its version history, or send it to Outlook. The right link in one click, with no hunting in the browser.

Two minutes from install to a working drive letter — no IE, no sync, no copies, and co-authoring left exactly where Microsoft put it.

Want the backstory — the terabyte library, the conflicted copies, the tools that flattened our version history? Read the developer story that led to OneMount →

Sources