chown -r 仅递归修改文件和目录的所属用户与组，不改变任何权限位；需配合 chmod 设置读写执行权限，并注意符号链接、挂载点及用户组存在性验证。
chown -R 只改归属，不碰权限
chown -R 的作用非常明确：递归修改目录下所有文件和子目录的所属用户与所属组，但完全不改变任何权限位（比如 644 还是 755，它不管）。很多人误以为它能“设置权限”，其实是混淆了 chown 和 chmod。
常见错误现象：执行 chown -R www-data:www-data /var/www/app 后，PHP 脚本突然 500，不是因为归属没改对，而是原来 config.php 是 600，现在依然 600 —— 但 web 用户没读权限；或者日志文件被设成 755，其实不该有执行位。
- 只改用户：
chown -R deploy /path - 只改组：
chown -R :www-data /path或chown -R .www-data /path - 同时改用户和组：
chown -R deploy:www-data /path - 必须用
sudo（或 root）——普通用户无法把文件转给他人
先确认目标用户和组是否存在
执行前漏查 id 或 getent，会导致命令静默失败（尤其在 CI/CD 脚本里），后续服务起不来才排查。
使用场景多见于部署 Laravel、WordPress、Node.js 应用，例如：
- Debian/Ubuntu 环境常用
www-data组，确认存在：getent group www-data - CentOS/RHEL 常用
apache组：getent group apache - 检查用户：
id deploy，不存在就先useradd deploy - 路径写错一个字符（比如
/var/www/app/多了个斜杠），chown会报No such file or directory，但若路径存在而空，它不会提醒你“改了个寂寞”
为什么不能只靠 chown -R 完事
归属改完，只是解决了“谁拥有它”，但没解决“谁能读/写/执行”。Web 服务器拒绝访问、PHP 报 open_basedir 错误、Git 钩子脚本不运行……八成是权限没跟上，而不是归属不对。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
典型组合操作顺序（不可颠倒）：
- 先跑：
sudo chown -R deploy:www-data /var/www/myapp - 再跑目录权限：
find /var/www/myapp -type d -exec chmod 755 {} \; - 再跑文件权限：
find /var/www/myapp -type f -exec chmod 644 {} \; - 单独放开可执行脚本：
find /var/www/myapp -name "*.sh" -exec chmod 755 {} \; - 敏感配置文件要收紧：
chmod 600 /var/www/myapp/.env
注意：chmod -R 755 /path 看似省事，但会让 .log、.json 全带 x 位，既不安全，又可能触发 SELinux 或容器环境拒绝策略。
容易被忽略的坑：符号链接和挂载点
chown -R 默认不处理符号链接本身（只改它指向的目标），但如果你用的是 -h 选项，就会改链接文件自己的归属——而链接文件通常不该有独立归属，改了反而破坏语义。
更隐蔽的问题是挂载点：
- 如果
/var/www/myapp/logs是单独挂载的磁盘（比如/dev/sdb1），chown -R会进入并尝试修改，但若该文件系统是noexec或nosuid挂载，或用了不同 UID 映射（如 NFS、bind mount），归属可能“看起来改了”，实际不生效 - 验证方式不是只看
ls -l，而是进到那个子目录里单独ls -ld .，再对比父目录 - 遇到跨文件系统挂载，建议拆开处理：
chown -R deploy:www-data /var/www/myapp，再单独处理/var/www/myapp/logs
归属递归这事，表面是一条命令，背后得盯住用户、组、路径、挂载、权限四层，少验一层，上线就报错。
