Permissions 为IIS 7.5和Windows Server 2008 R2下的ASP.NET授予网络UNC文件夹的写入权限 布鲁夫

我们的应用程序正在尝试使用在.NET 4.5、IIS 7.5和Windows Server 2008 R2下运行的ASP.NET web服务将文件写入UNC文件夹。但是，任何将文件写入所需位置的尝试都会导致访问被拒绝异常

这项任务似乎很简单，但我和我的团队已经对此进行了一段时间的故障排除，我们很难确定是什么原因导致了错误。下面是我们设置的详细信息，以及到目前为止我们尝试和发现的内容。为了保护无辜者，名字已经改变了

环境设置 web服务器mywebserver有一个名为My.Site.Com的网站，其相应的应用程序池名为My.Site.Com。应用程序池的配置如下所示

 .NET Framework Version     : v4.0
 Enable 32-bit Applications : False
 Managed Pipeline Mode      : Integrated
 Name                       : My.Site.Com
 Identity                   : ApplicationPoolIdentity
 Load User Profile          : False

我们试图写入的UNC路径是\myotherserver\mydirectories\output，其中mydirectories是实际共享。在此共享上，名为mygroup www的域组已被授予对共享和所有子文件夹的完全权限。机器帐户（即mywebserver）是此mygroup www组的成员

注意：目前，此UNC路径实际上位于同一条路径上 机器，mywebserver。然而，这最终将被转移到另一台机器上 比我们的测试环境和生产环境中的mywebserver更重要 当它准备好了。目前，我只有一个测试环境进行故障排除

可以通过执行以下代码来复制错误

[WebMethod]
[ScriptMethod(UseHttpGet = false, ResponseFormat = ResponseFormat.Json)]
public string ExportReport(int reportId)
{
    try
    {
        string output = ConfigHelper.OutputPath + "test.html"; // UNC path
        string url = ConfigHelper.VirtualPath + "test.html";
        string[] lines = { "Hello", "World!" };
        File.WriteAllLines(output, lines);                     // Access Denied!
        return url;
    }
    catch (System.Exception ex)
    {
        Logger.ErrorException("Error exporting report", ex);
        throw;
    }
}

故障排除 失败的尝试 我们尝试了对文件夹（如下所列）的组/用户权限的各种组合。在运行这些测试时，我们还运行了Process Monitor。对于每个配置，我们都看到了相同的结果。w3wp.exe进程试图在所需位置创建文件，但报告了访问被拒绝的结果。每个配置的用户都是IIS APPPOOL\My.Site.Com，如预期的那样

授予mydomain\mymachine$对\myotherserver\MyDirectory的完全权限

授予mydomain\mymachine$对\myotherserver\MyDirectory\output的完全权限

注意：我还尝试过修改代码，使其能够读取 来自\myotherserver\mydirectories\output的简单文件。什么时候 试图读取文件时，进程失败，访问被拒绝 写入文件时的消息

成功的尝试 我们还尝试了几种有效的配置

授予本地IIS APPPOOL\My.Site.Com权限 第一种配置是授予IIS APPPOOL\My.Site.Com对\myotherserver\mydirectories的完全权限。该文件已成功写入，但该进程的用户意外地成为为另一网站中同一台计算机上的web应用程序设置的域帐户。这仍然非常令人困惑，但由于“其他”帐户也具有对共享的写入权限，因此可以正常工作

这在生产中不起作用，因为我们不能使用本地帐户来授予对网络资源的访问权限，但这仍然是一个有趣的数据点

将应用程序池标识更改为域用户 第二个有效的配置是将My.Site.Com应用程序池的Identified to domain帐户更改为对\myotherserver\MyDirectory具有完全权限的帐户。这是我们手动创建的“普通”域帐户。我们没有捕获流程的用户是什么，但这可能是另一个有用的数据点

此选项可能是可行的，但是它脱离了IIS 7.5的最佳实践，并且由于相当严格的it政策，在我们的生产环境中可能不允许使用此选项

在我的开发机器上运行该站点 第三个测试是在我的开发机器mydevmachine上本地运行该站点。我的本地IIS配置与mywebserver相同，只是我运行的是Windows 7而不是Windows Server 2008。我已将mydomain\mydevmachine的完全权限授予\myotherserver\MyDirectory，并运行了该应用程序。文件已成功写入。根据Process Monitor，进程的用户已正确设置为IIS APPPOOL\My.Site.Com

结论 我们希望使用mywebserver的机器帐户启用设计的写访问。我们读了又读

根据此信息，我们应该能够使用机器帐户授予对网络资源（如UNC路径）的读写访问权。事实上，当从我的开发机器上运行网站时，我可以用期望的方式来完成这项工作

我想到了一些想法。也许测试web服务器的机器帐户有问题。或者“其他”软件以某种方式干扰了该过程

有没有想过是什么导致了这个问题？我们还应该做什么来排除故障

重新启动“mywebserver”

惊奇于现在功能神秘的ApplicationPoolIdentity

安装MS HotFix并了解有关此错误的详细信息，其中还显示了重现和演示此明显随机问题的步骤。直接下载链接

猜测为什么微软在热修复程序发布后的3年内没有发布一个正常的windows更新程序。然而，人们仍然因为这个模糊的问题而不断地撞到它并拔出他们的头发

了解其他人，他们分享并享受了微软的这一礼物，而微软仍在继续提供：

---

您的Windows7dev计算机可能工作正常，因为它比服务器更频繁地重新启动。祝贺你写得非常好，而且是一份全面的bug报告。在这里我很少看到这种情况。

我在ASP.NET应用程序中使用AppPoolIdentity访问网络共享时遇到类似问题（访问被拒绝）。 使用NetworkService帐户或其他域帐户