chown命令需root权限才能修改文件所有者，普通用户仅可修改自有文件的所属组；常见失效原因包括未加sudo、目标用户不存在、文件系统只读或NFS/容器环境不支持chown。
只有 root 或 sudo 用户能改文件所有者，普通用户只能改自己拥有的文件的所属组，不能改所有者。
chown user file 为什么没生效？
常见现象是执行 chown alice test.log 后 ls -l test.log 显示所有者没变，也没报错。原因通常是：
- 没加 sudo，普通用户对非自有文件无权修改所有者
- 目标用户 alice 不存在（查 /etc/passwd 或运行 id alice 确认）
- 文件在只读文件系统上（如挂载了 ro 选项）
- 用了 NFS 或某些容器环境，底层不支持 chown（返回 silent failure）
chown user:group 和 chown user.group 有啥区别？
冒号 : 是标准、安全的分隔符；点号 . 容易出歧义：
- chown dev:ops file → 所有者 dev，组 ops
- chown dev.ops file → 如果系统里真有个用户名叫 dev.ops，它会尝试把所有者设成 dev.ops，组默认为其主组；如果不存在该用户，就报 invalid user
- 更稳妥的做法是用数字 ID：chown 1001:1002 file，完全绕过名称解析和符号歧义
chown -R /path 为什么会让服务崩掉？
递归修改最危险的地方不是命令本身，而是路径选错或没意识到 -R 的真实作用：
- chown -R www-data:www-data /var/www/html 是常规操作
- 但写成 /var/www 就可能覆盖 /var/www/cgi-bin 或 /var/www/error 下的配置脚本属主，导致 Apache/Nginx 启动失败
- chown -R 默认会顺着符号链接钻进去改目标文件，不是改链接本身；想改链接自身得加 -h
- 执行前务必用 find /path -maxdepth 2 -ls | head -15 抽样确认范围，别依赖“我以为只改了这个目录”
真正容易被忽略的点是：chown 不报错 ≠ 成功。静默失败很常见，尤其是权限不足又没加 sudo 时——它不会说“Permission denied”，而是直接跳过。每次执行后，抽样 ls -l 几个关键文件，比看命令回显更可靠。
