使用 UNC 路径作为 Mercurial IIS6 Server2003 中的路径位置
我正在运行最新的 Mercurial 和 Python 2.6； IIS6 使用通配符 ISAPI 方法将站点附加到 Mercurial hgwebdir_wsgi
[paths]
\ = \\COMP3254\TestRepo\*
[web]
baseurl = /
allow_push = *
push_ssl = false
style = monoblue
如果我引用本地驱动器 E:\repo*，则该设置可以正常工作，但如果我如上所述指定网络，则该设置不起作用；我已授予服务器 (MERCDEV01$) 对 COMP3254 上共享文件夹的完全权限，我想不出它无法工作的任何其他原因。
I'm running the latest Mercurial and Python 2.6; IIS6 is using the wildcard ISAPI method to attach the site to the Mercurial hgwebdir_wsgi
[paths]
\ = \\COMP3254\TestRepo\*
[web]
baseurl = /
allow_push = *
push_ssl = false
style = monoblue
The setup works perfectly if I reference the local drive E:\repo* but doesnt work if I specify the network as above; I've given the server (MERCDEV01$) full permissions on the shared folder on COMP3254, I can't think of any other reason it wouldn't work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
可能是委托问题。您可以对网络服务器进行 NTLM 身份验证（并且您的凭据将在其本地驱动器上受到信任），但网络服务器无法对远程位置进行身份验证，因为它不知道您的密码（即它无法委派您的凭据） ）。
您是否尝试过将网络位置设置为服务器上的虚拟目录？然后，您可以输入 IIS 将缓存并用于访问该位置的凭据。
Could be a delegation problem. You can NTLM-authenticate to the webserver (and your credentials will be trusted on its local drives), but the webserver can't authenticate you to a remote location, because it does not know your password (i.e. it can't delegate your credentials).
Have you tried setting up the network location as a virtual directory on the server? You can then enter credentials IIS will cache and use for accesses to that location.
hgwebdir 也不适用于 UNC 路径 - 这意味着如果不在与 Web 服务器相同的计算机上托管存储库，则无法将其用作服务器。
hgwebdir doesn't work for me either with UNC paths - It means you can't use it as a server without hosting the repos on the same machine as the web server.
好吧..我解决了。运行Web服务器的用户（在我的例子中是Apache）默认为本地系统，它没有访问网络资源的权限。当我将其更改为具有域访问权限的用户（并授予该用户对本地计算机的管理员访问权限）时，一切正常。
以这种权限运行网络服务器当然是有风险的——但就我而言，它是一个内部服务器。想必您可以选择正确的权限以更安全的方式执行此操作。
Ok.. I solved it. The user running the web server (Apache in my case) defaulted to Local System, which does not have permission to access network resources. When I changed it to a user with domain access (and gave that user admin access to the local machine) everything worked fine.
Running a web server with that sort of privilege is of course risky - but in my case it is an internal server. Presumably you can cherry pick just the right permissions to do this in a more secure manner.