1

我在通过 WPI 安装的 Win2k8/IIS7（使用 httpcache、fastCgi 和 UrlRewriter 2.0）上运行 WordPress。一切似乎都运行良好（上传、通过 Live Writer 发布、评论、插件、漂亮的 URL）。

我正在尝试将 WordPress 更新到最新版本，但出现如下错误：

下载失败。文件流的目标目录不存在或不可写

这与我在尝试下载主题或更新插件时遇到的错误相同。

事件日志中没有错误，WordPress 并没有真正告诉我它正在寻找哪个目录、它认为它正在使用什么用户或它缺少什么权限。

我已经两次（和三次）检查了 IIS 应用程序池用户是否已明确设置，并且该目录具有该用户的修改权限，最后这些权限已被传播到子文件夹。

在 Google 博士的建议下，我还在配置文件中添加了以下设置：

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

define('WP_TEMP_DIR', ABSPATH . 'wp-content/');
define('FS_METHOD', 'direct');

我是否缺少配置选项或设置？WordPress 是否需要牺牲一只小猫和/或一只阿尔及利亚八齿狗？

4

2 回答 2

9

从关于 IIS7 安装的 PHP 手册（强调我的）：

模拟和文件系统访问

建议在使用 IIS 时在 PHP 中启用 FastCGI 模拟。这由php.ini 文件中的 fastcgi.impersonate 指令控制。启用模拟后，PHP 将代表已由IIS 身份验证确定的用户帐户执行所有文件系统操作。这确保即使在不同的 IIS 网站之间共享相同的 PHP 进程，只要在每个网站上使用不同的用户帐户进行 IIS 身份验证，这些网站中的 PHP 脚本将无法访问彼此的文件。

例如，IIS 7 在其默认配置中启用匿名身份验证，并使用内置用户帐户 IUSR 作为默认身份。这意味着为了让 IIS 执行 PHP 脚本，必须授予 IUSR 帐户对这些脚本的读取权限。如果 PHP 应用程序需要对某些文件执行写操作或将文件写入某些文件夹，那么 IUSR 帐户应该对这些文件具有写权限。

正如“我应该通过 FastCGI 模拟 PHP 吗？”中所讨论的那样。关于 ServerFault的问题，如果您授予匿名用户在您的服务器上的写访问权限，则会存在安全问题。例如，如果您还启用了 WebDAV 模块，任何人都可以使用此协议写入您的目录！

因此我的建议是：

  1. 确保您的所有站点都分配了自己独特的应用程序池。
  2. 在应用程序池的处理模型下的高级设置中，将内置帐户设置为.ApplicationPoolIdentity
  3. 使用禁用php.ini中的模拟fastcgi.impersonate = 0，以便 PHP在 IIS 中设置的应用程序池标识下运行。
  4. 使用自动生成的应用程序池用户帐户（例如“IIS AppPool\MyAppPoolName”）设置文件夹的读/写权限。

这样，确保所有 PHP 脚本在系统帐户下运行，绑定到站点的应用程序池（将其与其他站点隔离），并且不会通过模拟意外获得过于公开的访问权限。

于 2012-06-28T13:53:39.570 回答
2

如果我错了，请纠正我，但我相信以下配置提供了相同的好处，并且还尊重 PHP 所需的 fastcgi.impersonate=1 设置。

步骤 1,2 和 4 相同 - 步骤 3 不同。

  1. 确保每个站点都有自己的应用程序池（同上）
  2. 在 Advanced Settings > Processing Model > Application Pool Identity 下（同上）
  3. IIS > 身份验证 > 匿名身份验证 > 应用程序池标识（不是 IUSR）
  4. 使用 IIS AppPool\MyAppPoolName 设置读/写权限（同上）

我们不授予 IUSR 或 IIS_IUSRS 对 webroot 的访问权限。所有权限都分配给 IIS AppPool\MyAppPoolName

于 2013-04-19T16:18:55.117 回答