结论：CentOS 7 修改用户所属组须用 usermod，-g 改主组（影响新建文件默认属组），-G 改附加组（需加 -a 以免清空）；改组后需重新登录才能生效，chgrp 仅改文件属组，与用户组成员身份无关。
直接说结论：CentOS 7 中修改用户所属组，核心靠 usermod，但必须分清「主组（primary group）」和「附加组（supplementary groups）」——改错参数会导致用户登录失败或权限丢失。
usermod -g 和 -G 的区别必须搞清
usermod -g 改的是主组，即 /etc/passwd 第四字段（GID），这个组决定用户新建文件的默认属组；
usermod -G 改的是附加组列表，写在 /etc/group 里，用于赋予额外权限，但不改变新建文件的默认属组。
常见错误现象：
- 执行
usermod -G developers alice后，groups alice看不到developers→ 因为没加-a，旧附加组被清空了 - 执行
usermod -g root alice后，alice 无法登录 → 主组设成root通常没问题，但如果该组在/etc/shadow或 SELinux 策略中受限，会触发认证失败 - 用户改完组后，对已有文件仍无访问权 → 组变更只影响后续会话，当前 shell 进程的组信息不变，需重新登录或用
newgrp
实操建议：
-
usermod -a -G docker,nginx alice：把 alice 加入多个附加组，-a（append）不能漏 -
usermod -g developers alice：重设主组，确保developers在/etc/group中存在且非系统保留组（如root、bin） - 改完立刻验证：
id alice查 GID 和 groups 列表，getent group developers确认组存在且含该用户
为什么改完要重新登录？
Linux 登录时从/etc/passwd 读取主组，从 /etc/group 计算附加组，并缓存到进程的 credentials 中。运行中的 shell 不会自动刷新这些信息。
典型表现：
CentOS Linux 7.9.2009
下载
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
- 执行
usermod -a -G wheel alice后，su -c 'whoami' - alice仍报Permission denied -
groups命令输出没变，但id显示新组 → 说明新组已生效，只是当前 shell 没加载
解决办法只有两个：su - alice 新建登录会话，或直接退出重登。别指望 source ~/.bashrc 能刷新组信息。
chgrp 不能用来改用户属组
chgrp 是改「文件或目录的所属组」，不是改「用户所属的组」。混淆这两者是新手高频错误。
容易踩的坑：
-
chgrp -R developers /home/alice→ 改的是目录属组，和用户 alice 的组成员身份完全无关 - 误以为改了文件属组就等于让用户获得了权限 → 忘了还要看该用户是否在
developers组里，以及文件权限位是否开放（比如drwxr-x---对组是r-x，但若用户不在组里，照样进不去） - 用
chgrp改/home/alice属组后，alice 自己创建的文件属组仍是原主组 → 因为主组没变，新建文件默认继承主组
真正需要关注的其实是权限协同：用户属组 + 文件属组 + 文件权限位（如 g+rwx）三者缺一不可。改组只是其中一环，漏掉任意一个，权限都不生效。
