nginx启动进程对文件的权限掌控

最近在启动二进制的nginx时,总是遇到一个报错信息:/usr/local/nginx/client_body_temp/0000000018" failed (13: Permission denied);然后一直不怎么,明白,为啥要报这个错误,就开始去检查文件的权限

第一步:检查nginx启动目录下,文件的权限

找到nginx的启动目录,然后进入目录:

bash 复制代码
[AD\y ~]$ whereis nginx
nginx: /usr/local/nginx
[AD\y ~]$cd /usr/local/nginx
[AD\yc ~]$ ll
total 36
drwx------  2 nobody root 4096 Apr  2 18:30 client_body_temp
drwxrwxr-x  2 cwos   cwos 4096 Mar 27 14:47 conf
drwx------  2 nobody root 4096 Mar 25 11:16 fastcgi_temp
drwxr-xr-x  2 cwos   cwos 4096 Mar 25 10:49 html
drwxrwxr-x  2 cwos   cwos 4096 Mar 27 14:48 logs
drwx------ 12 nobody root 4096 Mar 27 14:53 proxy_temp
drwxrwxr-x  2 cwos   cwos 4096 Mar 25 10:49 sbin
drwx------  2 nobody root 4096 Mar 25 11:16 scgi_temp
drwx------  2 nobody root 4096 Mar 25 11:16 uwsgi_temp

查看文件的大部分是属于root和cwos用户的,然后我们查看nginx进程的启动用户是那个

bash 复制代码
[AD\y nginx]$ ps -aux|grep nginx
AD\yckj+  5801  0.0  0.0 112808   968 pts/0    S+   14:49   0:00 grep --color=auto nginx
root     26741  0.0  0.0  41864  1552 ?        Ss   Mar27   0:00 nginx: master process /usr/local/nginx/sbin/nginx
nobody   26742  0.0  0.0  54728  5884 ?        S    Mar27   0:03 nginx: worker process
[AD\ynginx]$

从结果中我们知道nginx的worker process进程是nobody用户,master进程是root启动的,也就是说实际执行nginx.conf中的静态文件执行工作的是nobody,接着我们检查nginx的配置文件中user信息

第二步:查看nginx配置文件nginx.conf

bash 复制代码
[AD\yc nginx]$ cd conf/
[AD\yc conf]$ cat nginx.conf

#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}

发现配置文件中user信息为注释状态,则nginx的工作进程就默认使用nobody用户进行启动了,然后我们继续探究报错的文件:usr/local/nginx/client_body_temp,对于nobody而已有可执行的权限,于是我看了这个目录的权限,果然这个目录client_body_temp,对于nobody没有可读写执行的权限,于是我改了这个目录的权限:

bash 复制代码
#切换成root用户
[root@client_body_temp]# cd ..
[root@ nginx]# ls
client_body_temp  conf  fastcgi_temp  html  logs  proxy_temp  sbin  scgi_temp  uwsgi_temp
[root@ nginx]# ll
total 36
drwx------  2 nobody root 4096 Apr  2 18:30 client_body_temp
drwxrwxr-x  2 cwos   cwos 4096 Mar 27 14:47 conf
drwx------  2 nobody root 4096 Mar 25 11:16 fastcgi_temp
drwxr-xr-x  2 cwos   cwos 4096 Mar 25 10:49 html
drwxrwxr-x  2 cwos   cwos 4096 Mar 27 14:48 logs
drwx------ 12 nobody root 4096 Mar 27 14:53 proxy_temp
drwxrwxr-x  2 cwos   cwos 4096 Mar 25 10:49 sbin
drwx------  2 nobody root 4096 Mar 25 11:16 scgi_temp
drwx------  2 nobody root 4096 Mar 25 11:16 uwsgi_temp
[root@jsglz-ibiscp2021ndddkf-dev-ocr-f2u9ua nginx]# chown nobody:root -R client_body_temp/
[root@jsglz-ibiscp2021ndddkf-dev-ocr-f2u9ua nginx]#

第三步:修改目录权限后,再次查看nginx的error日志

修改目录权限后,再次在页面上访问nginx代理的页面,观察后端ngin日志

bash 复制代码
[root@ nginx]# cd logs/
[root@ logs]# ls
access.log  error.log  nginx.pid
[root@ logs]# tail -100f error.log
2026/03/25 11:52:45 [error] 18609#0: *68 directory index of "/data/cwos/cbs-real-front//" is forbidden, client: 10.135.8.103, server: _, request: "GET /cbs-real/ HTTP/1.1", host: "10.128.165.129", referrer: "http://10.128.165.129/cbs-real/index.html"
2026/03/25 11:57:17 [notice] 17067#0: signal process started

果然报错日志不再是之前的信息,说明nobody用户已经有了执行目录client_body_temp的权限了

题外话

此外,在这次nginx权限处理的过程中,我顺便解决了另外一个权限文件,问题也和权限有关,保存信息如下:2026/03/25 14:15:10 error 17074#0: *160 directory index of "/data/cwos/cbs-shield-front//" is forbidden , client: 10.135.8.103, server: _, request: "GET /cbs-shield/ HTTP/1.1", host: "10.128.165.129", referrer: "http://10.128.165.129/cbs-shield/index.html"

原因是我在浏览器页面上访问nginx配置的静态文件路径,结果浏览器一直返回404,然后nginx后端日志就一直提示forbidden,我就查看了目录/data/cwos/cbs-shield-front的权限,如下:

bash 复制代码
[root@ cbs-shield-front]# ll
total 9156
drwxrwxrwx 5 cwos cwos      99 Dec  2 17:04 cbs-shield
-rwxrwxrwx 1 cwos cwos 9371843 Mar 25 14:45 cbs-shield-front-5.2.1.202603061804.tar.gz
drwxrwxrwx 6 cwos cwos     112 Apr 22  2025 home
drwxrwxrwx 3 cwos cwos      24 Mar  6 17:51 portal

发现整个目录的所有文件都是rwx状态,而且全部都是777,说明整个目录已经有可执行权限了,然后我就很不理解,为啥nginx不能正常访问这个目录下的静态文件,各种纠结和询问同事之下,才知道,这个/data/cwos/cbs-shield-front/目录,每一个层,nobody用户都得拥有可执行权限,才能正常访问静态文件成功,于是我逐层网上查看权限,如下图:

bash 复制代码
[root@jsglz-ibiscp2021ndddkf-dev-ocr-f2u9ua cbs-shield-front]# cd ..
[root@jsglz-ibiscp2021ndddkf-dev-ocr-f2u9ua cwos]# ll
total 392220
drw-rw-rw- 5 cwos cwos       100 Mar 26 16:39 cbs-shield-front
...
[root@j cwos]# cd ..
[root@j data]# ll
drwx------ 29 cwos        cwos                 4096 Mar 27 15:34 cwos

终于我找到原因了,这个目录/data,没有可执行权限,这个目录/data/cwos,也没有可执行权限,于是我把这两个目录的可执行权限,加上,赋予所有用户后,浏览器页面上的访问终于不再报404...,我在服务器上也能正常访问通了,如下:

bash 复制代码
[root@jrf cbs-ibis-front]# curl -X GET http://10.128.175.98/cbs-shield/home/index.html
<!doctype html><html lang=""><head><meta charset="utf-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width,initial-scale=1"><link rel="icon" href="favicon.ico"><title>****</title><script defer="defer" type="module" src="js/chunk-vendors.2a17b061.js"></script><script defer="defer" type="module" src="js/app.a1df35db.js"></script><link href="css/chunk-vendors.5a7fd0e2.css" rel="stylesheet"><link href="css/app.cbdd3ed9.css" rel="stylesheet"><script defer="defer" src="js/chunk-vendors-legacy.2ce98c45.js" nomodule></script><script defer="defer" src="js/app-legacy.141e4c1f.js" nomodule></script></head><body><noscript><strong>We're sorry but **** doesn't work properly without JavaScript enabled. Please enable it to continue.</strong></noscript><div id="sub-app"></div></body></html>[root@jrf cbs-ibis-front]#

总结:nginx代理的静态文件路径地址,如:http://10.128.175.98/cbs-shield/home/index.html

bash 复制代码
 location /cbs-shield {
        alias /data/cwos/cbs-shield-front/;
        try_files $uri $uri/ /cbs-shield/portal$uri /cbs-shield/portal/cbs-shield/index.html;
    }

这种静态文件的访问,内部一般包含js等脚本,所以文件是需要执行的,不是直接返回的,需要整个目录的文件夹都有可执行权限,否则就会报404未授权

相关推荐
qq_316411036 小时前
商用冷柜售后报修运维管理系统开发案例
运维
智码看视界6 小时前
Day59-阿里云ACK实战:生产级K8s集群部署与运维
运维·阿里云·kubernetes·k8s·日志监控·容器运维·阿里云ack
码视野8 小时前
基于 Vue3 + Element Plus 的【智慧新能源汽车充电桩运维调度与分时共享租赁系统】设计与实现(附完整源码与PRD)
运维·人工智能·汽车·vue3
qq_426003968 小时前
【UI自动化测试】UI自动化报错解决方案
运维·ui·自动化
网安蟹佬霸8 小时前
WAF绕过技术实战:从规则检测到编码绕过全指南(2026最新版,附Payload集与自动化脚本)
运维·安全·网络安全·架构·自动化·网安
小杨不想秃头8 小时前
信息安全工程师教程第二章密码学
运维·服务器·密码学
I'mChloe9 小时前
WGCLOUD怎么监控多台服务器?从Server、Agent 部署到监控面板实战
运维·服务器
Android系统攻城狮9 小时前
Linux PipeWire深度解析之pw_init调用流程与实战(八十三)
linux·运维·服务器·音频进阶·pipewire音频进阶
国科安芯9 小时前
轨道供电韧性:ASP4644四通道降压架构在低轨卫星平台电源管理中的适用性分析
运维·网络·数据库·嵌入式硬件·架构·状态模式·低轨卫星星座
Python自动化直播10 小时前
周末测试直播自动化时,发现一个棘手的并发问题
运维·自动化