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?
The command I've been using is mklink /d "C:\Finance Drive" "Q:\Public\Quick Books Data\Finance Drive"
Any ideas why this isn't working?
EDIT: I have gone into the security profile and specified that the Users group has permission to create symbolic links in addition to Administrators.
Best Answer
Try creating the link to
\\servername\sharename\Public\Quick Books Data\Finance Drive
instead of the mapped driveQ:
. On my Windows 7 x64, it turns out, both methods work, however.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 inWinObj
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):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:
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 theLanManRedirector
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 toL:\\
andC:\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.