chmod 和 chown 怎么用：Linux 权限排查别再一把梭 777

很多 Linux 权限事故，最开始都是一句话：

“先 chmod -R 777 试试。”

这类做法短期看像是把问题解决了，长期看往往是在把系统状态改乱，尤其在 /etc、/var、SSH 相关目录上风险很大。

先说结论

权限排查时要先分清两件事：

• 这是“权限位不对”的问题
• 还是“所属用户 / 所属组不对”的问题

前者主要看 chmod，后者主要看 chown。

一、先读懂 rwx 是什么意思

Linux 常见权限串长这样：

-rw-r--r--
drwxr-xr-x

可以拆成三组：

• 第一组：所有者权限
• 第二组：所属组权限
• 第三组：其他用户权限

其中：

• r 是读，数值是 4
• w 是写，数值是 2
• x 是执行，数值是 1

所以：

• 755 = rwxr-xr-x
• 644 = rw-r--r--

二、chmod 改的是“权限位”

数字方式

chmod 755 deploy.sh
chmod 644 application.yml

常见经验：

• 脚本文件经常用 755
• 普通配置文件经常用 644

符号方式

chmod u+x deploy.sh
chmod g-w config.txt
chmod o-r secret.txt

这种方式更适合做小范围精确调整。

三、chown 改的是“归属关系”

chown nginx:nginx /data/www
chown -R app:app /opt/service

它回答的是：

• 这个目录到底归谁
• 哪个用户运行的进程应该有权限访问它

很多权限问题，本质不是 rwx 错了，而是目录虽然看起来有写权限，但运行进程根本不是那个用户。

四、为什么不能动不动就 777

777 的含义是：

• 所有人都可读
• 所有人都可写
• 所有人都可执行

风险很明显：

• 文件被误改的概率升高
• 安全边界基本形同虚设
• 某些系统目录权限被改坏后，服务可能直接异常

尤其不要对下面这些路径做粗暴递归授权：

• /etc
• /var
• /usr
• /root
• SSH、Nginx、系统服务相关目录

如果真的出了问题，优先做的是：

• 先确认运行用户是谁
• 再确认目录归属和权限位
• 最后只修改必要路径

五、几个高频场景

1. 脚本没有执行权限

chmod +x start.sh

2. Nginx 或应用进程读不到目录

先看进程用户：

ps -ef | grep nginx

再看目录归属：

ls -ld /mydata/nginx /mydata/nginx/html

必要时：

chown -R nginx:nginx /mydata/nginx/html
chmod 755 /mydata/nginx

3. 上传目录无法写入

通常要同时看：

• 应用进程的运行用户
• 目录归属
• 上层目录是否有执行权限

六、排查权限问题时更稳妥的顺序

可以按这个顺序查：

1. whoami 看当前用户
2. ps -ef 看服务进程实际运行用户
3. ls -l 或 ls -ld 看文件和目录权限
4. 必要时再用 chmod 或 chown

如果一开始就递归改权限，往往会丢掉最重要的现场信息。

七、一个容易忽略的点

目录的 x 权限不只是“执行”。

对于目录来说，它更接近“可进入、可遍历”。

这也是为什么有些目录即使看起来可读，仍然进不去。

一句话总结

chmod 改的是权限位，chown 改的是归属关系。

权限问题最怕的不是不会改，而是不分原因就直接 777。真正稳妥的做法，是先搞清楚谁在访问、访问哪个路径、缺的是哪一种权限。