服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

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

我在这里search了一下,发现了一些其他的问题,但是没有其他的问题与我的IIS和应用程序的设置完全匹配。 首先是一些背景。 我公司的一个客户想要一次一个的内部应用程序重写他们的位。 我进入了项目,没有控制最初的IIS设置,似乎有一些时髦的东西不能正常工作,但我会做到这一点。 第一个位是一个自定义标签应用程序,它将文件写入要打印的文件共享。 为了维护需要的遗留应用程序的一部分,我在IIS中创build了一个单独的站点,并将所有旧版标签应用程序代码移动到那里。 我也在他们的默认网站下创build一个新的子应用程序。 所以结构看起来像这样: IIS 默认网站 新的标签应用程序(目前与旧版应用程序完全相同的代码库) 旧版标签应用 默认网站正在名为ASP.NET v4.0的应用程序池标识下运行,而不是DefaultAppPool,新应用程序正在以站点 – 标签命名的应用程序池标识下运行。 问题 新标签的子应用程序可以写入文件共享,不会有任何问题,但遗留站点正在获取拒绝访问。 这是完全相同的代码库,两者之间的唯一区别是正在使用的应用程序池。 我想单独维护这些应用程序池,但目前它们的设置是一致的。 因此,这使我相信,在我涉足ASP.NET v4.0应用程序池标识的某些方面,神奇地有权访问文件共享,而新创build的标签帐户不会。 文件共享对Everyone组是开放的,所以不应该有任何来自域级别的问题,但是从我所了解的这些生成的IIS帐户是虚拟IIS AppPool域的一部分。 那么,一个应用程序池标识如何访问,而不是一个呢? 我可以在故障排除过程中采取哪些步骤?