布鲁夫
我们的应用程序正在尝试使用在 .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 组的成员。
NOTE: For the moment, this UNC path actually lives on the same machine, mywebserver. However, this will eventually be moved to a machine other than mywebserver in our test environment and in the production environment when that it is ready. Currently, I only have the one test environment to troubleshoot with.
可以通过执行以下代码来复制错误。
[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。
NOTE: I have also tried modifying the code so that it would read a simple file from \myotherserver\mydirectories\output. When attempting to read the file, the process fails with an ACCESS DENIED message as it did when writing the file.
成功的尝试
我们还尝试了几种有效的配置。
授予本地 IIS APPPOOL\My.Site.Com 权限
工作的第一个配置是授予 IIS APPPOOL\My.Site.Com 对\myotherserver\mydirectories 的完全权限该文件已成功写入，但是该进程的用户意外地是为同一网络应用程序设置的域帐户机器在另一个网站。这仍然非常令人困惑，但因为“其他”帐户也具有共享的写入权限。
这在生产中不起作用，因为我们不能使用本地帐户授予对网络资源的访问权限，但仍然是一个有趣的数据点。
将应用程序池标识更改为域用户
有效的第二个配置是将 My.Site.Com 应用程序池的标识更改为对\myotherserver\mydirectories 具有完全权限的域帐户。这是一个由我们手动创建的“vanilla”域帐户。我们没有捕获流程的用户是什么，但这可能是另一个有用的数据点。
此选项可能是可能的，但它与 IIS 7.5 的最佳实践背道而驰，并且由于相当严格的 IT 策略，在我们的生产环境中可能不被允许。
在我的开发机器上运行站点
第三个测试是在我的开发机器 mydevmachine 上本地运行该站点。我的本地 IIS 配置与 mywebserver 相同，但我运行的是 Windows 7 而不是 Windows Server 2008。我将 mydomain\mydevmachine 的完全权限授予了\myotherserver\mydirectories 并运行了该应用程序。文件已成功写入。根据进程监视器，进程的用户已正确设置为 IIS APPPOOL\My.Site.Com。
结论
我们希望使用 mywebserver 的机器帐户按照设计启用写访问。我们已阅读 ApplicationPoolIdentity user cannot modify files in shared folder in Windows Server 2008和 Permissions for Shared Folder for IIS 7 Application Pool Identity Across Domain和 Application Pool Identities .
根据这些信息，我们应该能够使用机器帐户授予对网络资源(例如 UNC 路径)的读写访问权限。事实上，当从我的开发机器上运行网站时，我可以以所需的方式执行此操作。
有几个想法浮现在脑海中。可能是测试web服务器的机器账号有问题。或者也许是“其他”软件以某种方式干扰了该过程。
关于可能导致此问题的任何想法？我们还应该做些什么来排除故障？
最佳答案
您的 Windows 7 开发机器可能运行良好，因为它比服务器更频繁地重新启动。祝贺你写得非常好和彻底的错误报告。我很少在这里看到。
关于permissions - 在 IIS 7.5 和 Windows Server 2008 R2 下为 ASP.NET 授予对联网 UNC 文件夹的写入权限，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22240439/