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

我在这里search了一下，发现了一些其他的问题，但是没有其他的问题与我的IIS和应用程序的设置完全匹配。

首先是一些背景。我公司的一个客户想要一次一个的内部应用程序重写他们的位。我进入了项目，没有控制最初的IIS设置，似乎有一些时髦的东西不能正常工作，但我会做到这一点。第一个位是一个自定义标签应用程序，它将文件写入要打印的文件共享。为了维护需要的遗留应用程序的一部分，我在IIS中创build了一个单独的站点，并将所有旧版标签应用程序代码移动到那里。我也在他们的默认网站下创build一个新的子应用程序。所以结构看起来像这样：

IIS

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

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

问题

新标签的子应用程序可以写入文件共享，不会有任何问题，但遗留站点正在获取拒绝访问。这是完全相同的代码库，两者之间的唯一区别是正在使用的应用程序池。我想单独维护这些应用程序池，但目前它们的设置是一致的。因此，这使我相信，在我涉足ASP.NET v4.0应用程序池标识的某些方面，神奇地有权访问文件共享，而新创build的标签帐户不会。

文件共享对Everyone组是开放的，所以不应该有任何来自域级别的问题，但是从我所了解的这些生成的IIS帐户是虚拟IIS AppPool域的一部分。那么，一个应用程序池标识如何访问，而不是一个呢？我可以在故障排除过程中采取哪些步骤？

这只是我在这个答案中写到的IIS错误的另一个performance。你会发现重新启动修复它。修补程序可用。

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

在这里输入图像说明

这个错误导致我们的生产基地多次下降，并影响到客户。所以我不认为这个IIS 7.5修补程序是可选的，因为微软似乎通过拒绝通过标准更新通道解决这个问题在过去4年暗示。迫使客户“发现”生产停机时间这个bug是离谱的。