linux权限判断依赖进程的有效组id列表，而非理论组成员身份；需用id确认当前会话是否包含目标组，加组后必须重新登录或新开shell才能生效，否则组权限不被识别。
用户组权限不生效，不是组没加进去，而是系统根本没“认”你这个组成员身份。核心在于：Linux 权限判断依赖的是进程的 有效组 ID 列表，而不是你“理论上”属于哪个组。
确认当前会话是否真的拥有该组
运行 id 命令，重点看输出中 groups: 后列出的所有组名。如果目标组（比如 adm 或 docker）不在其中，说明当前 shell 进程并不携带该组权限。
- 用
sudo usermod -aG groupname $USER加组后，必须重新登录或打开一个新终端，id才会更新 - 如果在 SSH 会话中操作，需断开重连；在桌面环境中，可能需要注销再登录
- 临时验证可用
sg groupname -c 'id'，它会以指定组为附加组启动子 shell
检查文件或目录的属组与权限位是否匹配
执行 ls -ld /path（目录）或 ls -l /file（文件），关注两点：
- 第四列是否为你想匹配的组名（例如
root adm中的adm） - 权限字段第5–7位（属组权限）是否包含你需要的操作权限（如
r-x表示可读可进入目录，rw-表示可读写文件） - 注意：只要你是属主，就只看第2–4位；只有当你不是属主但属于属组时，才启用第5–7位——顺序不能跳过
排除 ACL 或更高层策略干扰
即使属组和权限都对，也可能被其他机制覆盖：
- 运行
getfacl /path，若输出末尾有# file: /path后带user::、group::等行，说明启用了 ACL；此时属组权限可能被显式 deny 规则屏蔽 - 运行
ls -Z /path查看 SELinux 上下文，若策略严格（如httpd_sys_content_t被拒绝访问），即使 chmod 正确也会报错 - 运行
mount | grep $(dirname /path)，确认挂载选项没有noexec、nosuid或mode=类参数压制权限位
验证是否真被组权限控制
临时切换到目标组身份测试，绕过当前 shell 的组缓存问题：
sudo -g groupname -u $USER -- bash -c 'ls -l /path/to/test'- 或更直接：
sg groupname -c 'ls -l /path/to/test' - 如果这时能成功，就坐实了是当前会话未加载该组；如果仍失败，说明问题出在文件归属、权限位或更高层拦截上
