There is a very specific moment in every NAS-and-cloud-drive setup where
something that used to work quietly stops working.
You mounted your storage as a drive letter. The files are there. You can open
them, you can drag them around, Explorer shows a normal-looking disk. And then
a backup job, an installer, or a sync client looks at that letter and decides
it is not a real disk and skips it. No error, no crash, just a line in a log
that says the target was skipped.
This is not a bug in the backup tool. It is the difference between two
completely different technologies that both end up looking like "a drive" in
the file manager.
The two worlds of "mounting" on Windows
User-mode redirect. A client process talks WebDAV (or SMB, or an
object-storage API) and exposes the remote content into the Windows namespace
through a per-user redirector. Explorer shows a shell icon, the drive sits
under Network Locations, and every I/O passes through that one process. This
is how most "cloud drive" tools and most WebDAV clients work.
Kernel-mode filesystem. A driver presents the remote share as a volume
through a filter-driver stack (the common approach on Windows is WinFsp).
Windows treats it like a disk: it appears under Devices and Drives, it has a
volume label, it participates in ACL resolution, it shows up in Device
Manager, and programs that shell out to the Win32 file APIs see a real volume
handle.
Backup agents, disk-quota policies, VSS writers, installer engines, and
BitLocker all make assumptions about the second kind. That is where the
"skipped" messages come from.
Five checks you can run in five minutes
1. Where does the letter appear? Open This PC. A real disk shows up
under Devices and Drives. A user-mode redirect shows up under Network
Locations, usually with a different icon. This is the fastest signal and it
is right more often than not.
2. Does Device Manager know about it? Press Win+X and open Device
Manager, then expand Disk drives. A kernel-mode mount registers a device
here, with the product's own device name. A user-mode redirect does not appear
here at all.
3. Can Windows read the ACL? Right-click the drive, Properties,
Security. A real disk shows an owner and a permission list you can edit. On
a remote mount, many servers simply do not return ownership information, so
Windows shows "Unable to display current owner" or an empty list. Some tools
hide this by disabling the security tab entirely, which is a warning sign in
itself.
4. Does the volume behave under load? Open Task Manager, Performance,
Disk, and look at the drive you mounted while copying a large file. With a
kernel-mode mount you see real IO on that volume. With a user-mode redirect,
the traffic shows up under the client process instead, and the "disk" stays
quiet.
5. Does an installer accept it? Run any installer that wants a target
folder and point it at the mounted drive. Real disks are accepted. Network
locations frequently are not, and the failure is usually a generic error that
gives you no hint about the real cause.
If check three or five fails, you are not dealing with a broken mount. You are
dealing with a tool that presents your storage as something the operating
system does not consider a disk.
Why the difference matters more than it looks
The obvious cost is that backups silently skip the data. The subtler costs
show up everywhere else:
- ACL-dependent workflows break. If your NAS serves per-user permissions and the mount cannot resolve them, a file that looks readable in Explorer may fail to open in the application that actually needs it.
- File locking semantics differ. WebDAV servers vary widely in how they handle locks. Some tools retry on lock failures, others give up and report a partial copy. A tool that retries forever will quietly tie up your whole backup window.
- Non-Latin filenames are a common failure. Some WebDAV servers do not return a charset in the response headers, and the client guesses wrong. Test a directory with Chinese, Japanese, or Korean names before you rely on it.
- Credential prompts interrupt unattended runs. If the mount asks for a password mid-job, the job stalls waiting for a human.
What to look for in a tool
Ignore the feature list for a minute and ask three questions instead.
Does it mount through a driver stack, so Windows sees a disk? Can it display
and honour the permissions the server actually returns, and does it tell you
plainly when the server does not return them? Does it cache credentials so an
unattended run does not stall on a prompt?
Where ScsDriver comes in
If you are on Windows and you want the storage to look like a disk rather than
a folder shortcut, that is the problem ScsDriver is built for. It mounts
WebDAV and NAS shares as real drive letters through a WinFsp-based kernel
driver, so the five checks above pass: the letter shows up under Devices and
Drives, the device registers under Disk drives, ACLs are read and honoured
where the server provides them, and CJK filenames are handled properly.
Credential caching keeps unattended jobs from stalling on a password prompt,
and a local cache layer means a short network blip does not immediately
freeze the file you are editing.
There is a 7-day full-feature free trial, so you can run your own version of
the five checks above before you commit to anything.
Pricing at the moment is a one-time $5.50 lifetime buyout, running as a
limited promotion priced at the one-year rate. There is nothing to renew
afterwards, and lifetime upgrades are included. The download is at
https://drive.scsoi.com
The one-minute version
Before you trust a mount with your backups, open This PC, then Device
Manager, then the security tab on the mounted drive. If the letter is under
Network Locations, if no device shows up under Disk drives, or if the
security tab cannot show an owner, your tools will keep skipping it, and no
amount of retry settings will fix that.
Pick a tool that makes the operating system agree it is a disk, and the
symptom disappears on its own.
