我们目前使用 Carbonite 进行文件备份。我有一台 NAS,上面有很多文件,除了订阅 Carbonite 的机器上的本地文件外,我还想用 Carbonite 备份这些文件。
我尝试为此创建一个符号链接,但无法正常工作。这是否适用于通过 Carbonite 备份 NAS 上的文件?
我一直使用的命令是 mklink /d "C:\Finance Drive" "Q:\Public\Quick Books Data\Finance Drive"
知道为什么这不起作用吗?
编辑:我进入了安全配置文件并指定用户组除了管理员之外还有权创建符号链接。
答案1
尝试创建链接到\\servername\sharename\Public\Quick Books Data\Finance Drive
而不是映射驱动器Q:
。在我的 Windows 7 x64 上,事实证明,这两种方法都有效。
另外,请确保您已经与远程服务器建立了会话(使用 进行验证net use
),除非它是不需要凭据的旧式 Windows 共享。
此外,确保 ACL 设置正确在符号链接上本身带有icacls /L
。不带 运行它/L
不会产生预期结果。这需要管理员权限,就像创建符号链接一样。
编辑1:
与我在此答案的早期版本中所写相反,事实证明对象和 I/O 管理器能够理解映射的网络驱动器(查找\Device\LanManRedirector
符号链接WinObj
位于下面的一个对象目录下\Sessions\0\DosDevices
)。刚刚测试了一下。
我还查阅了 Russinovich 等人编写的《Windows Internals》第 5 版(第 924 页及后续内容),因为你让我很好奇。你可能想检查一下fsutil behavior query SymLinkEvaluation
你的系统上符号链接的配置方式。默认配置为(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.
刚刚测试过,只要在共享和符号链接上正确设置 ACL,就可以符号链接 UNC 路径或映射驱动器号。但是,在符号链接上设置过于严格的 ACL 会导致失败。我针对旧式共享进行了测试和一个需要凭据的(在我的情况下是在域上,但我不在该域上)。
要列出 ACL,请使用:
icacls <symlink-name> /L
不过,我刚刚也在 Vista SP2 x64 上进行了测试,遇到了你遇到的问题如果我使用驱动器号作为目标路径,尽管符号链接评估策略设置与我测试的 Windows 7 SP1 x64 相同。
编辑2:
在 WinDbg 中,我跟踪了正在发生的事情。我首先决定检查mup
驱动程序,我知道它拥有LanManRedirector
其他设备对象。我的内核调试器是 Vista SP2,裸露与您看到的相同行为。
首先,我创建了一个到 的网络驱动器映射L:
,\\server\share
然后创建了两个符号链接:C:\Users\user\drv-name
指向L:\\
和C:\Users\user\unc-name
指向\\server\share
。
知道符号链接是重新解析点后,我决定列出 NTFS 驱动程序的所有函数(dt ntfs!* -v
)并选择最有希望设置断点:
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
当然,忽略了文件系统驱动程序是一件非常微妙的事情。Windows 用坚持不懈的错误检查提醒了我这一点0x24
。
不幸的是,系统重新启动后,即使在 Vista SP2 虚拟机上,这两个符号链接也能正常工作。这意味着我无法以任何一致的方式重现该问题。这意味着我暂时无法进一步深入挖掘。