When using "Windows Server Backup" in Windows Server 2008, I get the error message "The directory is not a subdirectory of the root directory." when trying to backup to a remote shared directory.

I am logged in through remote desktop, and the destination for the backup is "\\tsclient\c\users\me\desktop\backup\". Initially, it accepts this directory, and moves on to the final "Confirmation" step. When I click "Backup", it gives me the error message I mentioned.

Does anyone have any idea what this means, or why this particular remote shared directory would cause this message?

I've even tried mapping it as a drive and doing a backup to a local drive, but mapped drives don't show up in the local drive list. Also, this is a virtual machine (no other local drives, no dvd burners, and no other accessible machines on the LAN), so the tsclient remote shared folder seems like my only possible target for a backup destination. I was feeling so good about Windows Server 2008 until this happened... why can't their software ever just work :(.


The error message seems to mean literally what it states. I shared the target folder on my desktop and mapped it as a local drive "B", and made it available for remote desktop. When I use the path "\\tsclient\b", Windows Server Backup accepts it and begins transfering the data. So.. "\\tsclient\b" is a valid path, but "\\tsclient\b\subdirectory" is not? Wtf?


I think their software works fine, except that you're "pushing" a feature beyond its intended limits and seeing an artifact of a protocol implementation. I'm don't think that running backups through the TS client drive redirection feature is going to work. I would say that the "subdirectory" behaviour you're seeing is because of artifacts of the TS client drive redirection feature (which is its own protocol and not "normal" SMB2/CIFS/SMB file and print sharing).

I'm running the following command on a W2K8 server computer daily with success, for example:

%SYSTEMROOT%\System32\WBADMIN.EXE start backup -backupTarget:\\adminserver\backups\FTPServer -allCritical -quiet

The path specified there is another server computer accessible over SMB/CIFS. Backup to a subdirectory that way is no problem.

Is the a compelling reason not to just give the VM access to another machine via SMB2/SMB/CIFS?


You're misunderstand me when I say that you're "pushing" the feature. I'm not trying to "apologize" for them. The TS client drive mapping feature should act just like any other networked filesystem. It should be reliable enough to push potentially tens of gigabytes across in a backup scenario like you describe. It should work.

What I'm saying is: As far as I can tell, by looking at the "tone" of docs re: the TS client drive mapping feature it's intended to be used for casually moving data between the client the server. Further, it's a virtual channel protocol for RDP that's wholly and totally unrelated to SMB/CIFS, so it doesn't have the years of being "beaten on" that SMB/CIFS does.

I've heard reports of the feature being very unreliable when used as the location for saving documents from the Microsoft Office programs, for example. My take on this is that while this feature should work fine, it seems very likely that Microsoft isn't testing it for use as a general-purpose networked file system. As such, what you're doing is "pushing" the feature beyond its unstated design goals.

I'm right there with you re: UNC's making remote resources "just be a folder". The MUP driver should make any UNC act like "just a folder". After years of dealing with problems in older versions of the SMB redirector (remember "Oh, just disable oplocks", anyone?), the Novell Netware client, various NFS client implementations, and Microsoft's own WebDAV functionality I don't just trust any UNC-based network filesystem provider to work.

It's infuriating when I find a feature in any application or operating system that doesn't work "as advertised" (either from Microsoft or otherwise-- it just seems like Microsoft does it more often). What you're doing is the same thing that all of us in the industry do-- trying a feature out to see if it meets our real world requirements as well as the marketing gimmick requirements.

You're finding out that this feature doesn't meet your requirements. You have two choices-- complain to Microsoft or find a different way. To my mind, complaining to Microsoft is futile (unless you're a large enough Customer to attract attention with your complaints), so the alternative is to find another way.

That's why I said what I said. Not because I think you're doing anything wrong, because I'm apologizing for Microsoft's shoddy programming on this feature, or because I think it's right for the feature to be "sold" as being a true UNC-based networked filesystem drive when it's obviously "got issues". It is what it is, and you just have to deal with it or move on and find another way.

  • Normal use of any "feature" at all seems to automatically qualify as "pushing" it. It doesn't work as expected, and a specific error message admits it. TS client (an integrated OS service mind you), apparently needs some work to properly emulate a shared folder. If I make the path shorter, it works fine with the TS client. And all it does it basically write a VHD file to the path, so I don't understand what the big deal is. Apps I code have no problem writing files in deep paths for ts client drives. There's just no obvious reason why it shouldn't work, and that's the real problem. – Triynko Jul 4 '09 at 6:09
  • The VM is on a subnet where I neither own nor operate any other machines, so there are none for it to access. The whole point of a UNC path is to allow access to remote resources, and a folder is a folder, so either ts client needs to be fixed or the backup software needs to be fixed... or they need to put a disclaimer saying... oh, you aren't really sharing a folder with TS client... ur sharing something "like" a folder, but not quite... there are a few specific restrictions, such as... windows backup can't write to a folder unless its an immediate subdirectory of the root, etc. etc. – Triynko Jul 4 '09 at 6:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.