源码安装Nginx时空间不足或权限异常源于环境准备偏差,非编译本身失败:需预留≥500MB磁盘空间(尤其/tmp和源码分区),确保源码目录、--prefix路径及依赖库路径对当前用户可读写,全程普通用户操作仅make install加sudo,并验证sbin/nginx执行权、配置文件与日志目录权限闭环。
源码安装 Nginx 时遇到空间不足或权限异常,不是编译失败本身导致的,而是环境准备和操作路径出了偏差。问题往往在 configure 阶段就埋下伏笔,到 make 或 make install 时才集中爆发。
检查并释放足够磁盘空间
configure 和 make 过程会生成大量中间文件(如 objs/ 目录),尤其启用 SSL、HTTP/2 等模块后,临时对象体积明显增大。建议预留至少 500MB 可用空间:
- 用 df -h 查看 /tmp(configure 默认缓存目录)和源码所在分区的剩余空间
- 若 /tmp 满了,可指定临时目录:在 configure 前执行 export TMPDIR=/path/to/larger/dir
- make 完成后及时清理:进入源码目录运行 make clean,删掉 objs/ 和 .o 文件
确保编译用户对所有相关路径有完整权限
权限问题常出现在三类路径上:源码目录、安装目标目录(--prefix)、以及 configure 依赖库路径(如 --with-openssl=)。任意一处不可写或不可读,都会中断流程:
- 源码目录需保证当前用户有 rwx 权限(特别是解压后未改属主时,常见于 sudo wget + 普通用户编译)
- --prefix 指定的安装路径(如 /usr/local/nginx)必须存在且当前用户可写;若不存在,先 sudo mkdir -p /usr/local/nginx && sudo chown $USER:$USER /usr/local/nginx
- 若引用了自建 OpenSSL 或 PCRE(如 --with-openssl=/opt/openssl),确认该路径下 include/ 和 lib/ 对当前用户可读
规避 root 权限误用带来的权限残留
用 sudo 执行 configure 或 make 是危险操作——它会让生成的 Makefile、objs/nginx 等文件属主变为 root,后续普通用户无法修改或安装,还容易引发 make install 后二进制无执行权限(因 cp 替代 install):
- 全程使用普通用户操作,仅在 make install 阶段加 sudo(前提是 --prefix 目录已授权)
- 若已误用 sudo 编译,不要直接 chmod 修复 objs/nginx,而应 make clean 后切换回普通用户重做
- 更稳妥做法:configure 后检查 Makefile 中 install 目标是否调用 install -m 0755;若只是 cp,则手动用 install 命令覆盖安装
验证关键路径权限链是否闭环
编译成功不等于能运行。安装完成后立即检查权限闭环,避免启动时报 “Permission denied”:
- 确认 /usr/local/nginx/sbin/nginx 有 x 权限(ls -l 看是否有 x)
- 确认 nginx.conf 中 user 指令指定的用户(如 www-data)真实存在,且对该配置文件、logs/、client_body_temp/ 等路径有读写权
- 若用 systemd 管理,运行 systemctl status nginx,错误信息比手动执行更早暴露权限断裂点