chmod数字权限是三位八进制加法：r=4、w=2、x=1，如755表示所有者rwx（7）、组rx（5）、其他rx（5）；常见组合有644（文件安全底线）、755（目录可执行）、600（私钥铁律），误用777极不安全。
chmod 数字权限怎么算才不懵
数字权限本质是三位八进制加法：r=4、w=2、x=1，rwx 就是 4+2+1=7，rw- 是 4+2+0=6，r-x 是 4+0+1=5。别硬背，现场加就行。
常见组合不是随便来的：755 适合脚本或网站目录（所有者可改，别人只能看和进），644 是配置文件/HTML 的安全底线（别人不能改也不能执行），600 是私钥类文件的铁律（连组用户都不能碰）。
- 误把
777当“万能解”——等于把门敞开给所有人，Web 目录设这个可能被上传木马 - 对目录只设
644会进不去：cd需要 x 权限，没 x 就算有 r 也列不出内容 -
chmod -R 755 /var/www看似稳妥，但会把里面所有 .log、.conf 文件也变成可执行，nginx 可能直接拒启
chown 改所有者时为什么总提示 Operation not permitted
只有 root 或文件当前所有者才能执行 chown，普通用户不能把自己文件的所有者改成别人，也不能抢改别人文件——这是内核级限制，不是权限没开。
典型翻车场景是 Docker 容器里或 NFS 挂载点：即使你是 root，若挂载时用了 no_root_squash 以外的选项，chown 也会静默失败或报错。
- 想批量改目录下所有文件归属，必须加
-R，否则只改目录本身，里面文件还是老样子 - 写
chown user:group file时，冒号前后不能有空格；用点号（user.group）在用户名含小数点时会歧义，一律用冒号 - 目标用户或组必须真实存在于
/etc/passwd或/etc/group，否则报invalid user
chgrp 和 chmod g+s 配合用才有意义
chgrp 单独改组只是“当前快照”，新创建的文件不会自动继承。真要让协作目录里的文件始终属于同一组，得配 chmod g+s（SetGID 位）。
比如团队共用 /srv/project，先 chgrp devteam /srv/project，再 chmod g+s /srv/project。此后所有人在该目录下新建文件，组自动是 devteam，不用每次手动 chgrp。
-
chgrp -R能递归改已有文件，但对将来新建的无效——这点常被忽略 - 目录设了
g+s后，ls -l 显示组权限位的 x 会变成 s（如drwxr-sr-x），这是正常现象 - 普通用户只能把文件组改成自己所属的组，不能随意指定任意组名
umask 不是权限，而是“默认砍掉哪些位”
umask 值（如 0022）不是最终权限，而是从最大值里减去的部分：目录最大是 777，文件最大是 666（文件默认不可执行）。umask 0022 → 目录得 755，文件得 644。
临时调高安全性？umask 0077 让新文件仅所有者可读写；想让组协作更顺？umask 0002 保留组写权限。但注意：它只影响新创建文件，对已有文件完全没作用。
- shell 启动时读
~/.bashrc或/etc/profile里的 umask 设置，改完要source或新开终端才生效 - 某些服务（如 vsftpd、nginx worker）会重置 umask，不能只靠用户 shell 设置保底
- 脚本里用
touch或cp创建文件时，umask 生效；但echo > file这种重定向也受 umask 控制，容易被当成“例外”忽略
权限问题最麻烦的从来不是命令记不住，而是改了一处，另一处悄悄失效——比如修了 chown 却忘了目录的 x 位，或者设了 g+s 却没提前 chgrp 目录本身。动手前先 ls -ld 看一眼目标对象的当前状态，比反复试错快得多。
