We currently use Carbonite for our file back ups. I have an N.A.S. with a bunch of files on it that I would like Carbonite to back up in addition to the local files on the machine with the Carbonite subsciption.

I tried to create a symbolic link for this but haven't been able to get it to work right. Will this even work for backing up the files on the N.A.S. via Carbonite?

Hey! This is actually on another computer, thanks for all the help before. It won't let me do a junction because one of them is a remote file server, junctions will only work with local folders.
–
BlakeMar 4 '13 at 20:26

Also make sure that you have established a session with the remote server (verify with net use) unless it's an old style Windows share which doesn't require credentials.

Furthermore ensure that the ACLs are set correctly on the symlink itself with icacls /L. Running it without /L will not yield the expected results. This requires admin rights just like creation of the symlink will.

Edit 1:

Contrary what I wrote in an earlier revision of this answer it turns out the object and I/O manager are able to understand mapped network drives (look for \Device\LanManRedirector symlinks in WinObj under one of the object directories beneath \Sessions\0\DosDevices). Just tested it.

I also looked it up in Windows Internals, 5th edition, by Russinovich et al. (pages 924 and following), because you got me curious. You might want to check with fsutil behavior query SymLinkEvaluation how symlinks are configured on your system. Default would be (also on Vista SP2):

>fsutil behavior query SymLinkEvaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.

Just tested that it works to symlink the UNC path or the mapped drive letter as long as the ACL is set correctly on the share as well as on the symlink. Setting the ACL on the symlink too restrictive will cause failure, however.
I tested it both for an old-style share and one that requires credentials (in my case on a domain, while I am not on that domain).

To list the ACL use:

icacls <symlink-name> /L

However, I also tested on Vista SP2 x64 just now and I am running into the problem you're running into if I use the drive letter as destination path, although the symlink evaluation policy is set the same as for Windows 7 SP1 x64 on which I tested.

Edit 2:

In WinDbg I was tracking what's going on. I first decided to check the mup driver which I know owns the LanManRedirector among other device objects. My kernel debuggee was a Vista SP2 that exposed the same behavior you see.

First of all I created a network drive mapping L: to \\server\share and then two symlinks: C:\Users\user\drv-name pointing to L:\\ and C:\Users\user\unc-name pointing to \\server\share.

Knowing that symlinks are reparse points, I decided to list all functions of the NTFS driver (dt ntfs!* -v) and pick the most promising to set breakpoints on:

of course neglecting that the file system drivers are a very delicate thing. Which Windos reminded me of with an insistent bug-check 0x24.

Unfortunately after the system came up again, both symlinks worked even on that Vista SP2 virtual machine. This means I have no way of reproducing the issue in any consistent manner. It means I cannot dig any deeper for the time being.

@DavidMurdoch Oh wow, I completely forgot to follow up on this post after trying it. I honestly don't remember what happened with it since it's been so long, sorry about that. I know we resolved it somehow but I can't recall the exact means.
–
BlakeFeb 11 '14 at 19:31