☰

PHP-FPM + nginx 生成权限被拒绝，但仅在某些大型页面上

tag-icon • tag-icon nginx php php-fpm wordpress amazon-lightsail
PHP-FPM + nginx 生成权限被拒绝，但仅在某些大型页面上

我有一个 AWS Lightsail 实例（1GB RAM 实例），运行一个相对较新的网站（即几乎没有流量）。它运行 nginx 和 PHP-FPM 7.3（也尝试过 7.2）和 MariaDB。所有这些都在 CentOS 7 下运行。

在 AWS 免费套餐下，一切都运行良好。我运行了一个 T2.micro EC2 实例和一个 T2.micro RDS 实例。Lightsail 有点……棘手。为了让 Lightsail 正常工作，我将 PHP-FPM 切换到ondemand

ondemand - 启动时不创建子项。当有新请求连接时，将创建子项。

我必须这样做，否则 MariaDB 会随机崩溃。这似乎不会影响下面的问题。

Wordpress 管理面板停止正常工作，每个人都建议关闭CONCATENATE_SCRIPTS它。这基本管用……帖子和模板的编辑器都出现故障。没人能告诉我原因。四处寻找后，我自己发现了一些东西。

无法正常工作的页面无法完全加载。CONCATENATE_SCRIPTS启用后，CSS 文件会加载到一个巨大的页面中。由于无法完全呈现，浏览器会忽略 CSS 和 JS 文件。解决这个问题的CONCATENATE_SCRIPTS方法是简单地将它们拆分为组件文件，这些文件更小且易于加载。但编辑页面无法拆分，调试底层问题非常令人抓狂。我得到了 200 个响应和一些数据

页面返回 200

但页面绘制不完整。我认为可能有 80-90% 的 HTML 存在，但被截断了。从这里开始的部分（JS 块）

wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware( {"\/":{"body":{"name":"S

它只是突然结束，而且每次都在同一点。就好像 PHP-FPM 或 nginx 刚刚停止，但没有任何错误日志（并且关于此类设置的其他大多数问题都是页面根本没有绘制）。更奇怪的是，它不会对较小的页面这样做，只会对很长的页面这样做。没有窃取时间，top实例似乎也没有承受任何严重负载，所以我不确定它为什么会这样做。我重新加载了所有文件，甚至设置了一个单独的 WP 站点来测试这一点，它们都这样做了。

根据评论，我打开了 nginx 调试日志，发现

2019/08/07 02:33:08 [crit] 1461#0: *47 open() "/var/lib/nginx/tmp/fastcgi/3/00/0000000003" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: example.com, request: "GET /wp-admin/post-new.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000",

这根本说不通为什么它只对少数几个大文件这样做。没有驱动器是满的或接近满的。我读到这个问题但 nginx 和 PHP-FPM 都在 下运行apache。删除 tmp 文件也没有解决问题。目录归 拥有apache:root，但将其更改为apache:apache无效。SELinux 似乎也不是罪魁祸首。我也没有使用proxy_cache。

答案1

首先，失败与FastCGI 缓冲，而不是代理缓存。

从 可以看出这一点/var/lib/nginx/tmp/fastcgi...。

为什么只有在特别大的页面上才会遇到错误：如果你配置的 FastCGI 缓冲区不足以将 PHP-FPM 的整个响应放入内存中，当然，如果回应量很大，这种情况会更常见，NGINX 将尝试将响应的部分内容写入临时文件。

显然，用于保存 FastCGI 临时文件的目录的权限不允许 NGINX 在其中保存文件，因此当响应“太大”时，它会在某个时候失败。

该路径/var/lib/nginx/tmp/fastcgi还表明您没有使用官方的 NGINX 发行版，因为如果您这样做了，那么您最终将/var/cache/nginx/fastcgi_temp拥有nginx:root。

我建议使用原装的、官方的 NGINX 发行版。

但 nginx 和 PHP-FPM 都在 apache 下运行

离题了，但是：无论如何，这都是不正确的设置。正确的设置是作为一个用户（无论是 还是其他任何用户）运行 NGINX apache，nginx而应用程序的 PHP-FPM 池在其自己的用户下运行，例如foo。然后让您的nginx用户成为组成员foo。没有理由只因为您在给定服务器上只有一个应用程序而以单个用户身份运行所有内容。

不管怎样，把它当做一个典型chmod问题来对待：

  • 检查 NGINX 工作进程以哪个用户身份运行（user配置中的指令）
  • 尝试使用该用户从上到下列出相关目录的文件，直到找到停止工作的位置，然后递归修复权限。

例如，假设您的 NGINX 工作进程确实如您所说，由apache用户运行，并且它无法访问/var/lib/nginx/tmp/fastcgi：

sudo -u apache ls /var/

这有效吗？权限没问题，您可以通过 NGINX 工作进程的用户遍历到此目录。重要的是要了解，您需要能够遍历（如rx权限）到所有上层目录，以便能够读取下层任何目录的内容。也就是说，对于我们的“最终目的地”，即/var/lib/nginx/tmp/fastcgi，我们需要能够读取所有/var、/var/lib等。

如果阅读/var不起作用（尽管这说明系统存在某种腐败），你需要让“其他人”阅读它，例如chmod o+rX /var

sudo -u apache ls /var/lib

这有效吗？ /var/lib 的权限没问题。如果不行，你需要允许其他人读取它：chmod o+rX /var/lib

sudo -u apache ls /var/lib/nginx

这有效吗？如果不行，请通过 检查所有权和权限stat。然后确保 NGINX 用户是目录的所有者/var/lib/nginx，并且chmod（这次是“所有者”）允许它遍历目录：

chown apache:root /var/lib/nginx
chmod u+rX /var/lib/nginx

确保相同（由 NGINX 用户拥有，可以被其读取（遍历））/var/lib/nginx/tmp

最后，/var/lib/nginx/tmp/fastcgi您将需要 NGINX 用户能够执行所有读取、执行（遍历）和写入操作：

chown apache:root /var/lib/nginx/tmp/fastcgi 
chmod 0700 /var/lib/nginx/tmp/fastcgi

因此，基本上，这是一个冲洗、重复操作，同时遍历相关文件，直到起作用为止。

通过尝试列出目录的内容并在其中创建文件来验证一切是否设置正确：

sudo -u apache ls /var/lib/nginx/tmp/fastcgi
sudo -u apache touch /var/lib/nginx/tmp/fastcgi/test.txt

相关内容