What I Learned Mounting a WebDAV Share as My Default Working Drive in 2026

What I Learned Mounting a WebDAV Share as My Default Working Drive in 2026

For about three months I have been running with a WebDAV share mounted as my W: drive in Windows. Every project I work on for the first 30 minutes of the day lives on W:. Here is what worked, what did not, and what I would do differently if I was starting over.

The setup

I am using ScsDriver ($5.5 lifetime) pointed at a WebDAV endpoint I control. The install was about two minutes. The mount is registered as a real drive letter, not a network redirect, which means it survives reboots without a startup script and behaves like a USB drive for every Windows tool I use.

What worked

• The W: drive is just there every morning. I do not have to think about it.
• Editors that do not hold exclusive locks (VS Code, Sublime, plain text files) are fine. Open, edit, save, no lag.
• Streaming large media files is fine because the client streams rather than copying to a local cache.
• A git status over a project with a few thousand files is fast enough to not be annoying.
• My backup strategy got simpler: the share is the source of truth, and W: is the working copy.

What did not work at first

• The first week I had the WebClient file size limit hit me on a 600 MB virtual disk. Switching to a real mount client fixed it.
• I tried to keep a Lightroom catalog on the share. SQLite file locking is not friendly to network files, so the catalog would occasionally lock up. I keep the working catalog local and the originals on the share.
• I tried to keep an Outlook PST on the share. Same story, exclusive locks. PST stays local.
• A 4K video edit directly off the share was fine for playback, but the export took longer than the same export on a local drive. For final renders I copy down.

What I would do differently

• Test the file size limit early. The 50 MB Windows default will bite you.
• Keep any app that uses exclusive file locking on local storage, not the share.
• Pick a mount client that streams rather than copies, otherwise the open and save path will be slow on large files.
• Make sure the mount survives reboot. A startup script is fine, a service is better.

Cost vs. friction

For a one-time $5.5 the savings on my time are pretty clear. I would still pay the same for the reboot-survive guarantee and the lack of a startup script, which I would otherwise have to write, debug, and maintain.

If you are thinking about doing the same thing, the two questions to answer first are: (1) which apps do you need to keep on local storage, and (2) how big are the files you will be opening and saving. Once you have those, the rest is just picking a mount client and pointing it at your endpoint.