ASP.NET/IIS7.5 写入日志文件不起作用（权限、UAC、配置。？？？）答案

【问题标题】：ASP.NET/IIS7.5 Writing Log File Not Working (Permissions, UAC, Config., ???)ASP.NET/IIS7.5 写入日志文件不起作用（权限、UAC、配置。？？？）
【发布时间】：2011-08-24 12:45:33
【问题描述】：

我们在将 ASP.NET 应用程序迁移到 Windows Server 2008 R2 x64 和 IIS7.5 时遇到问题。问题是我们的 ASP.NET 应用程序写入日志文件，而这些日志文件没有被写入。应用程序写入其日志文件的唯一方法是，如果我以本地管理员用户身份登录服务器，或者如果我右键单击并以管理员身份运行 IE，这两种方法都不是我们可接受的解决方案。

我们的平台是： Windows Server 2008 R2 x64（UAC 设置为默认设置） IIS7.5 ASP.NET 4.0（在 web.config 中使用 Windows 身份验证和模拟）

我们的应用安装到： D：[应用程序名称] [appnameWebSite]（所有的.aspx、.dll等文件都在这里） \Log（应用程序尝试将日志文件写入此文件夹）

在服务器上：创建了新的应用程序池（名称：[appname]，.NET 4.0，托管管道模式：经典，身份：ApplicationPoolIdentity，加载用户配置文件：False，所有其他属性都是默认值）创建指向 D:[appname][appnameWebSite] 的 IIS 应用程序并将其添加到新的应用程序池（完全信任级别）在本地管理员组中拥有域用户

使用上面列出的所有配置和默认设置，ASP.NET 应用程序将不会写入日志文件。该应用在浏览器中似乎可以正常工作，但没有 log.txt 文件。

为了尝试“修复”这个问题，我们尝试了很多方法：尝试过的应用程序池设置：托管管道模式：集成尝试过的应用程序池设置：身份：NetworkService 尝试应用程序池设置：身份：LocalSystem 尝试过的应用程序池设置：加载用户配置文件：真让用户组完全控制我们的应用程序文件夹结构的文件系统（尝试过 appname 文件夹，仅尝试过 Log 文件夹，仅尝试过 appnameWebSite 和 Log 文件夹）让 IIS AppPool[appname]（匹配新的 App Pool）用户完全控制我们的应用程序文件夹结构的文件系统（尝试过 appname 文件夹，仅尝试过 Log 文件夹，仅尝试过 appnameWebSite 和 Log 文件夹）

这些都没有帮助。同样，应用程序运行良好，只是没有创建日志文件。

如上所述，在应用程序运行时创建日志文件的唯一方法是，如果我们使用本地管理员帐户（这很有意义，因为他是超级用户）登录服务器，或者我们以管理员身份运行 IE 并且提升权限。

有什么建议吗？帮助？有问题吗？

谢谢！

【问题讨论】：

标签： asp.net permissions iis-7.5 uac application-pool

【解决方案1】：

我在这个问题上挣扎了一段时间。 ApplicationPoolIdentity 是 Users 组的成员，而 Users 组的访问权限有限。

在资源管理器中，右键单击您要写入的文件夹并转到安全性。单击高级按钮。您将看到用户具有读取和执行权限，用户组可能具有也可能没有特殊权限。如果没有，请单击更改权限并让用户能够创建文件/写入数据和创建文件夹/附加数据。这仅限于此文件夹。我通常使用子文件夹，这样我就不会提供对整个网站的写入权限。

再次尝试创建日志文件。这是我需要设置的唯一权限才能使其正常工作。

【讨论】：

感谢您提供的信息。我已经尝试在 Log 文件夹上使用文件系统权限，但仍然没有运气。正如我之前提到的，我有一个域用户在服务器的管理员组中。我以该域用户身份登录服务器。我将本地用户组完全控制（读取、写入、所有内容）授予文件系统中的 Log 文件夹（即，用户组完全控制 D:\appname\Log）。请注意，本地管理员组已经拥有对文件系统日志文件夹的完全读/写/修改控制（继承）。仍然没有创建日志文件。
我将实际的域用户完全控制（读取、写入、所有内容）授予了文件系统中的 Log 文件夹（即，域用户完全控制了 D:\appname\Log）。仍然没有创建日志文件。我给了 IIS AppPool[appname]（匹配新的 App Pool）用户对文件系统中的 Log 文件夹的完全控制权（读、写、一切）（即，IIS AppPool[appname] 用户完全控制了 D:\应用程序名\日志）。仍然没有创建日志文件。
我将本地 IIS_IUSRS 组完全控制（读、写、一切）交给了文件系统中的 Log 文件夹（即 IIS_IUSRS 组完全控制了 D:\appname\Log）。仍然没有创建日志文件。这些东西都没有帮助。因此，我尝试为所有相关用户和组提供完整的文件系统控制权，但仍然没有日志文件。我认为这不可能是文件系统权限问题。
有什么建议吗？帮助？问题？谢谢！
哇——我会仔细看看我的配置，以防有任何其他可能提供线索的东西。这听起来像是一个安全问题，因为当您以管理员身份运行时它确实有效，但是您将所有权限授予所有用户，所以它应该可以工作。

【解决方案2】：

好吧，在尝试了每个 IIS 选项、用户和组帐户、文件系统权限、进程资源管理器等天之后，我认为我们已经成功了：

我们将所有 IIS 应用程序池和网站设置重置为默认值
我们还将日志文件夹上的文件夹/文件系统权限重置为默认设置
然后我们关闭了服务器上的 Internet Explorer 增强安全配置

成功了！无论什么用户使用 ASP.NET 应用程序，无论他们是在服务器本身还是从工作站运行它，日志文件都会按预期写入。

我不知道关闭服务器上的 Internet Explorer 增强安全配置是否是“正确”的做法，或者它是否违反了任何最佳实践，但它似乎对我们有用。

大家有什么要补充的吗？

【讨论】：

【解决方案3】：

我尝试授予所有可能的权限，但仍然没有获得任何日志文件。最后我遇到了this，它建议更改我的日志文件目录的所有权。我检查了一下，目录所有权设置为SYSTEM。我将其更改为管理员并递归应用更改。我反弹了 IIS，在浏览器中从该站点访问了一个网页，现在我有了日志文件。万岁！

注意：提示我的是检查系统事件日志。我收到 15006 错误提示“日志文件或目录 C:\inetpub\logfiles\W3SVC1\some.log 的所有者无效。这可能是因为另一个用户已经创建了日志文件或目录。”

【讨论】：

【解决方案4】：

对我来说，诀窍是让SYSTEM 和Administrators 的写入权限不仅可以写入日志文件夹本身，而且还可以写入路径中的每个文件夹。这不是权限在 Windows 中通常的工作方式，但 IIS 似乎对此非常特别。并不是说有充分的理由从 ACL 中删除这两个。

如果您怀疑这是问题所在，请检查 Windows 日志/系统下的事件日志。此问题表现为来自源 HttpEvent 的错误条目，并显示“无法创建日志文件 C:\path\to\logs\W3SVC1\u_extend1.log。确保日志记录目录正确且此计算机对那个目录。”

附：这适用于 IIS 10，但也可能适用于其他版本。

【讨论】：