LNMP在Ubuntu上如何解决权限问题

LNMP在Ubuntu上的权限问题排查与修复

一、先统一运行身份与目录归属

确认服务运行用户：Nginx 主进程通常以www-data运行（查看**/etc/nginx/nginx.conf首行的 user 指令）；PHP-FPM 的运行用户由/etc/php/*/fpm/pool.d/www.conf中的user与group**决定，两者需与站点目录属主一致或具备相应访问权限。
统一目录属主与权限：将网站根目录（如**/var/www/html或/usr/share/nginx/www**）及其子目录属主设为www-data:www-data，并设置目录为755、文件为644，避免过宽的777。
示例（按需替换路径）：
- 设定属主：sudo chown -R www-data:www-data /var/www/html
- 设定权限：find /var/www/html -type d -exec chmod 755 {} + && find /var/www/html -type f -exec chmod 644 {} +
说明：目录需要执行位（x）以便进入与列目录，文件一般不需要执行位。上述属主与权限是 Ubuntu 上 Nginx/PHP-FPM 的常见实践。

二、按症状快速定位与修复

访问 PHP 页面出现空白或 500，且页面显示“File not found.”
- 常见于 PHP-FPM 以socket方式与 Nginx 通信时，Nginx 配置中的SCRIPT_FILENAME使用了错误的**$document_root**，或目录/文件对www-data不可读。
- 修正示例：
  - fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  - 确保 root 指向实际站点目录，且目录/文件权限与属主正确。
访问 PHP 页面出现 500，日志提示 open_basedir 限制
- 说明 PHP 被限制在某个目录树内，项目引用了上级目录文件。
- 处理：在php.ini或Nginx 的 server/fastcgi 配置中调整open_basedir，将其放宽到项目根目录的上级（或直接注释以禁用该限制），然后重启服务。
上传/写入失败（如 WordPress 无法更新、生成缓存）
- 为需要写入的子目录（如wp-content/uploads、storage、cache）单独赋予www-data写权限：
  - 示例：sudo chown -R www-data:www-data /var/www/html/wp-content/uploads
  - 仅对需要写入的目录放宽权限，避免过度授权。
目录列表被禁止但期望显示
- 在需要的 location 中临时加入**autoindex on;**用于排查，生产环境不建议长期开启。
访问 .php 直接下载而非解析
- 检查 Nginx 是否正确处理 PHP 的 location、是否配置了fastcgi_pass（如127.0.0.1:9000或unix:/run/php/php*.sock），以及SCRIPT_FILENAME是否正确。

三、关键配置与日志位置

建议的 Nginx 片段（确保 fastcgi_param 使用**$document_root**）：
- location ~ .php$ {
  - include snippets/fastcgi-php.conf;
  - fastcgi_pass unix:/run/php/php8.1-fpm.sock; # 版本号按实际调整
  - fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  - include fastcgi_params;
- }
修改配置后务必先执行：sudo nginx -t（语法检查），再执行：sudo systemctl reload nginx。
日志定位：
- Nginx 错误日志：/var/log/nginx/error.log
- PHP-FPM 错误日志：常见为**/var/log/php**-fpm.log 或 /var/log/php-fpm/error.log（路径随版本与发行版而异）
- MySQL 错误日志：/var/log/mysql/error.log
服务管理：sudo systemctl status|restart|reload nginx，sudo systemctl status|restart|reload phpX.Y-fpm。

四、安全加固与最佳实践

最新问答