linux服务器权限继承依赖属组设定、setgid位（2775）与目录默认权限协同；用户主组决定新建文件默认属组，附加组用于批量授权，setgid确保新文件自动继承目录属组。
Linux 服务器上，用户组管理不是简单地把人“拉进一个群”，而是权限落地的关键枢纽；权限继承也不是自动发生的，它依赖明确的机制触发——核心是 属组设定 + SetGID 位 + 目录默认权限 三者协同。
用户组的本质与主/附加组分工
每个用户必须有且仅有一个主组（primary group），通常与用户名同名，新创建的文件默认归属该组。附加组（secondary groups）则用于“授予权限”：只要用户属于某个组，就自动获得该组对文件或目录的访问权限。
- 主组决定新建文件的默认属组，不可删除（即使组内只剩一人）
- 附加组可增可删，数量不限（最多31个），是批量授权的主要手段
- 查看归属关系用
id 用户名，比groups更完整（含 UID/GID 和所有组）
让新文件自动继承目录所属组：SetGID 是关键
普通目录下，用户创建的文件属组仍是自己的主组，而非目录属组——这常导致协作失败。解决方法是在目录上启用 SetGID 位（即权限中的 s 或数字 2）：
- 设置命令：
chmod 2775 /path/to/dir（2 表示 SetGID） - 效果：该目录下新建的文件/子目录，属组自动设为该目录的属组，而非创建者主组
- 前提：用户必须同时属于该目录的属组，否则权限不生效
权限继承的完整链条：从创建到生效
一个文件能否被组内其他成员编辑，取决于三个环节是否连通：
-
身份层面：用户必须属于目标组（通过
usermod -aG groupname user添加） -
目录层面：父目录需设为该组属组，并开启 SetGID（
chown :groupname dir && chmod 2775 dir） -
文件层面：文件自身权限需开放组写（如
chmod g+w file），或依赖 umask 默认允许（如 umask 002）
常见误区与验证方法
权限看似设了却无效？先检查这几个点：
- 用
ls -ld /target/dir看目录权限末尾是否为s（如drwxr-sr-x），不是说明 SetGID 没生效 - 新建测试文件后，立即执行
ls -l testfile，确认属组是否等于目录属组 - 切换到另一组员账号，尝试
touch或echo >，不要只看ls -l就断定能写
