为什么我只能在一个 ApplicationPoolIdentity 下访问我的文件共享？

Question

我在这里搜索了一下，发现了一些可以尝试的方法，但其他问题都没有与我的 IIS 和应用程序设置发生的情况完全匹配。

首先，介绍一些背景知识。我公司的一个客户想要一个内部应用程序，一次重写他们的部分内容。我加入该项目时无法控制初始 IIS 设置，而且似乎有些奇怪的事情无法正常工作，但我会讲到的。第一个部分是一个自定义标签应用程序，它将文件写入文件共享以进行打印。为了维护所需的旧版应用程序部分，我在 IIS 中创建了一个单独的站点，并将所有旧版标签应用程序代码移到那里。我还在他们的默认网站下创建了一个新的子应用程序。因此结构看起来像：

互联网信息服务

• 默认站点
  • 新的标签应用程序（目前与旧版应用程序的代码库完全相同）
• 旧版标签应用程序

默认站点在名为 ASP.NET v4.0（而不是 DefaultAppPool）的应用程序池标识下运行，而新应用程序在以站点 - 标签命名的应用程序池标识下运行。

问题

新标签的子应用程序可以毫无问题地写入文件共享，但旧站点被拒绝访问。这是完全相同的代码库，两者之间的唯一区别是正在使用的应用程序池。我想单独维护这些应用程序池，但目前它们的设置相同。所以这让我相信在我参与之前在 IIS 中设置了一些东西，其中 ASP.NET v4.0 应用程序池标识以某种方式神奇地可以访问文件共享，而新创建的标签帐户则不能。

文件共享对 Everyone 组开放，因此域级别不应该存在任何问题，但据我所知，生成的这些 IIS 帐户无论如何都是虚拟 IIS AppPool 域的一部分。那么，为什么一个应用程序池标识有访问权限，而另一个没有访问权限？在故障排除过程中我可以采取哪些步骤？

Answer 1

这只是我在这个答案。你会发现重启可以解决这个问题。热修复可用。

您的两个网站的不同行为只能归因于它们运行的​​两个不同的应用程序池标识。您没有明确提到身份工作池和非工作池。“标签”是应用程序池。检查池属性以查看其以何种身份运行，并将其与旧池的身份进行比较。

此错误已导致我们的生产站点多次瘫痪，并对客户产生了影响。因此，我认为此 IIS 7.5 补丁不是可选的 - 微软似乎在过去 4 年中一直拒绝通过标准更新渠道解决此问题，这似乎暗示了这一点。强迫客户在生产停机期间“发现”此错误是令人无法接受的。