Try creating the link to \\servername\sharename\Public\Quick Books Data\Finance Drive
instead of the mapped drive Q:
. 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 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:
kd> bp Ntfs!NtfsGetReparsePoint
kd> bp Ntfs!NtfsReparsePointName
kd> bp Ntfs!NtfsInitializeReparseFile
kd> bp Ntfs!_imp_FsRtlValidateReparsePointBuffer
kd> bp Ntfs!NtfsReparsePointString
kd> bp Ntfs!NtfsCreateReparsePointInternal
kd> bp Ntfs!NtfsGetReparsePointValue
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.
1I'm glad you did not give up, good quality. Test :
Junction "C:\FinanceDrive2" "Q:\Public\Quick Books Data\Finance Drive"
– STTR – 2013-03-04T20:19:27.040Hey! 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. – Blake – 2013-03-04T20:26:11.190
1
mklink "C:\FinanceDrive" "\\<ip address>\Public\Quick Books Data\Finance Drive" /D
? – STTR – 2013-03-04T20:34:26.297I'll try that as soon as I'm at the office Wednesday and let you know if it works. – Blake – 2013-03-05T04:35:48.980