用户加组后无权限，主因是新组未生效至当前会话；需新开终端或运行newgrp临时切换，且须确认usermod使用-aG而非-G覆盖，并验证目录执行位与服务进程所属组。
用户加了组却没权限，多数不是命令没敲对，而是组信息没真正“生效”到当前会话里。关键要区分“系统记录已改”和“进程实际能用”这两层。
确认当前会话是否加载了新组
执行 groups 或 id -Gn，看输出里有没有刚加的组名。如果没出现，说明新加的组还没被当前 shell 读取——usermod -aG groupname username 修改的是系统配置，但不会自动刷新已有登录会话。
- 新开一个终端或 SSH 连接，再运行 groups，通常就能看到新组
- 不想重连？可临时切换组：运行 newgrp groupname，之后该 shell 就以该组为主组运行（注意：这会启动新子 shell）
- 图形界面登录用户尤其容易忽略这点——改完组必须完全退出桌面环境再重新登录
检查 usermod 是否误用了 -G 而非 -aG
-G 选项本身是设置“附加组列表”，不带 -a 就等于覆盖。例如：
- usermod -G docker alice → alice 的附加组只剩 docker，原来 sudo、plugdev 全没了
- usermod -aG docker alice → docker 被追加进已有附加组列表
执行后建议立刻用 id alice 核对 groups 字段，确认旧组还在。
验证目标文件/目录的组权限与执行位
即使用户属于某组，也得满足两个条件才能访问：文件属组匹配 + 对应组权限位开启 + 目录有执行（x）位（用于进入或遍历）。
- 用 ls -ld /path/to/dir 查目录权限，确保组位有 r-x（至少 x 才能 cd 进去）
- 普通文件只需对应权限位（如组读写：-rw-rw----），但若在某个目录下，该目录自身也必须对组开放 x 权限
- 注意 umask 影响新建文件的默认组权限，比如 umask 002 时新建文件组权限是 rw-，而 umask 022 则变成 r--
排查服务进程是否以正确用户身份运行
很多权限问题出在“你以为你在操作，其实是服务在替你操作”。例如 Web 应用写日志失败，不是你缺权限，而是 nginx 或 apache 进程以 www-data 用户运行，而它不属于你添加的那个组。
- 查进程真实用户：ps -eo pid,user,group,args | grep 服务名
- 模拟服务身份测试：sudo -u www-data groups，看它是否在目标组里
- 必要时把服务用户也加进对应组：sudo usermod -aG targetgroup www-data，然后重启服务
