在 Linux 服务器上设置上传权限，本质就三件事让 Web 或应用进程的运行用户成为上传目录的属主，把目录权限控制在 755 到 775 之间、文件控制在 644 到 664 之间，再用 setgid 或 ACL 保证新上传的文件自动继承正确的组和权限。 把这三步做扎实，九成以上的“上传失败”“写入被拒”都会消失。
先弄懂 rwx 在目录和文件上不是一回事
很多人一上来就 chmod -R 777，问题看似解决，后门也顺手开了，要改对权限，得先看清 Linux 的权限模型。
三组身份和三种权限
每个文件或目录都挂着三组身份：属主（u）、属组（g）、其他人（o），每组对应读（r=4）、写（w=2）、执行（x=1）三个位，数字表示法就是把三组的值拼起来，755 即属主 rwx、属组 r-x、其他人 r-x。
目录上的 x 位是“进门许可”
这是最容易被忽略的一点，文件上的 x 表示“可执行”，目录上的 x 表示“可进入、可穿越”，一个上传目录哪怕给了 rw-，只要没有 x，进程照样进不去，表现就是莫名其妙的 Permission denied，所以目录权限通常是 755 或 775，绝不会是 644。
文件的写权限取决于谁在写
PHP-FPM、Nginx、Tomcat、Node 进程各自以某个系统用户身份运行，用 ps aux | grep nginx 或 ps -ef | grep php-fpm 能看到实际的运行用户，常见的是 www-data、nginx、apache 或 www，上传失败的根因，往往是这个用户对目标目录没有 w 权限,而不是权限数字不够大。
Linux服务器网站目录上传权限怎么设置：一套可以照抄的流程
假设站点根目录是 /var/www/html，上传目录是 /var/www/html/uploads，运行用户是 www-data。
第一步：确认运行用户
ps -ef | grep -E "nginx|php-fpm|apache" | grep -v grep
输出里的第一列就是运行用户，不同发行版和安装方式差异很大，Debian/Ubuntu 系多为 www-data，CentOS/RHEL 系多为 nginx 或 apache，别凭印象写,一定要看实际进程。
第二步：用 chown 定归属
chown -R www-data:www-data /var/www/html/uploads
归属对了，后续权限才有意义，如果上传目录是由运维账号通过 SFTP 传文件、再由程序读取，属主可以设为运维账号，属组设为 www-data,让程序靠组权限写入。
第三步：用 chmod 定边界
find /var/www/html/uploads -type d -exec chmod 755 {} \;
find /var/www/html/uploads -type f -exec chmod 644 {} \;
分开处理目录和文件是关键，一条 chmod -R 755 会把所有文件也变成可执行,脚本文件被意外执行的风险随之上升。
第四步：用 setgid 让新文件自动继承组
chmod g+s /var/www/html/uploads
给目录加上 setgid 位后，目录内新建的文件和子目录会自动继承父目录的属组，而不是创建者的主组，多人协作或程序与运维账号混用的场景,这一位能省掉大量事后修权限的麻烦。
第五步：用 umask 兜底
程序创建文件时，最终权限等于“默认权限减去 umask”，Web 进程常见的 umask 是 0022，创建出的文件是 644、目录是 755，如果团队需要同组可写，把 umask 调整为 0002，产出就变成 664 和 775，umask 通常在服务配置文件或启动脚本里设置,改完要重启对应服务。
第六步：验证
sudo -u www-data touch /var/www/html/uploads/test.txt ls -l /var/www/html/uploads/test.txt
用运行用户真实地写一次，比看一百遍配置都管用,写完记得删掉测试文件。
上传文件权限不足怎么办：从报错信息倒着查
Permission denied 的三种典型现场
第一种，日志里明确写着 Permission denied，路径指向上传目录，八成是属主或属组不对，或者目录缺 x 位。
第二种，上传成功但程序读不到，多见于文件属主是 root、权限是 600，Web 进程根本没权限读，这类问题在上传组件以 root 身份运行时尤其常见。
第三种，上传目录能写，但子目录写不进去，原因是 setgid 没设，或者子目录权限被继承成了 644 这种“目录没有 x”的状态。
排查命令清单
namei -l /var/www/html/uploads/file.txt：逐级列出路径上每一层的权限,一眼看出卡在哪一级。ls -ld /var/www/html/uploads：看目录本身的权限和属主。getfacl /var/www/html/uploads：确认有没有 ACL 规则在干扰。tail -f /var/log/nginx/error.log：看真实报错,别猜。getenforce：SELinux 开着的话,权限数字再对也可能被拦。
775和777有什么区别，上传目录到底该给哪个
这是被问得最多的对比，行业共识认为，777 意味着任何本地用户都能写、能改、能删，一旦目录里存在可执行脚本,等于把执行入口直接暴露在公网。
| 权限 | 数字 | 属主 | 属组 | 其他人 | 适用场景 |
|---|---|---|---|---|---|
| rwxr-xr-x | 755 | 读写执行 | 读执行 | 读执行 | 单人维护的常规站点目录 |
| rwxrwxr-x | 775 | 读写执行 | 读写执行 | 读执行 | 程序与运维账号需要同组写入 |
| rwxrwxrwx | 777 | 全部 | 全部 | 全部 | 临时排障，绝不可长期保留 |
| rwxr-x— | 750 | 读写执行 | 读执行 | 无 | 含敏感数据的上传目录 |
结论很直接：上传目录用 755 起步，需要组内协作再放宽到 775，777 只作为临时诊断手段。 同一台机器上如果跑着多个站点,更要避免一个站点的漏洞横向波及全部目录。
多程序共用目录与云主机场景的处理方式
ACL 精准授权
当 Nginx 负责接收、PHP 负责处理、备份脚本又需要读取时，单靠属主属组摆不平，ACL 能给指定用户单独授权：
setfacl -R -m u:nginx:rwx /var/www/html/uploads setfacl -R -d -m u:nginx:rwx /var/www/html/uploads
第二条的 -d 是默认 ACL，作用是让之后新建的文件和目录自动带上这条规则,否则每次上传都要重新授权。
SELinux 与容器环境
CentOS/RHEL 上 SELinux 处于 enforcing 模式时,需要给上传目录打上可写标签：
chcon -R -t httpd_sys_rw_content_t /var/www/html/uploads
容器部署的场景则要同时检查宿主目录权限和容器内用户映射关系，宿主上是 755、容器内以 uid 1000 运行，照样写不进去，把容器运行用户与宿主目录属主对齐，或者用 -u 指定 uid,比盲目调权限更靠谱。
给普通用户开上传权限而不给 root
近年来越来越多的团队采用“运维账号登录 + 业务账号运行”的模式，做法是建一个专用组，把运维账号和运行用户都放进去，上传目录设为 root:uploadgrp、权限 775 并开启 setgid，这样普通用户能传能改，root 归属保证了目录不会被任意删除重建,权限边界清晰可控。
上传目录的安全底线
- 禁止在上传目录内执行脚本。 Nginx 里加一条
location ~ ^/uploads/.\.(php|jsp|sh)$ { deny all; },从入口切断。 - 上传目录独立分区或挂载 noexec。 挂载时加
noexec,nosuid,即便有文件落地也无法执行。 - 定期审计权限漂移。 用
find /var/www -perm -o+w -type d扫出“其他人可写”的目录，这类结果通常都是历史遗留的 777。 - 控制上传文件大小和类型。 在 Nginx 的
client_max_body_size和应用的 MIME 白名单两层拦截,权限只是最后一道闸。
据工信部相关安全通报，配置不当导致的目录遍历与写入漏洞长期位居 Web 风险前列，而权限过宽是最常见的诱因之一，权限设置的功夫，主要花在“刚好够用”这四个字上。
关于Linux服务器上传权限设置的常见问题
问：改完权限后程序还是传不上去，最可能漏了什么？
答：先确认改的是不是程序真正写入的路径，很多项目把上传目录配置在 /data/uploads 或项目内的 storage 目录，运维改的却是 /var/www/html/uploads，其次查 SELinux 是否开启、防火墙之外的挂载选项是否带 nosuid、以及是否启用了只读文件系统，用 sudo -u 运行用户 touch 目标路径 实测,一次就能定位。
问：上传目录到底该设 755 还是 775，有没有判断标准？
答：看“谁会往里写”，只有单一 Web 进程写入，755 加 setgid 足够；运维账号需要 SFTP 手动补传，或者多个进程共写，就升到 775 并把相关账号加入同一属组，判断依据是写入者的数量,而非权限数字越大越保险。
问：找人代配上传权限一般是什么价位？
答：单台云服务器的目录权限梳理，通常包含在常规运维服务里，按次处理的报价从几十元到两三百元不等；涉及多站点、容器化改造或 SELinux 策略调整的，会按工时计，自己动手的话成本基本为零，前提是先把运行用户和路径这两件事确认清楚，剩下的就是几条 chown、chmod 和 setfacl 命令。
上传权限设置不是把数字调大，而是把归属、边界、继承三条线一次对齐。 属主对了、目录有 x、新文件自动继承组,上传问题就不会反复找上门。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/777172.html
