usermod -g 修改用户主属组必须由root或sudo用户执行，修改后需重新登录生效；-g更新/etc/passwd第四字段gid并清除用户在/etc/group中的主组记录，目标组须预先存在。
usermod -g 修改用户主属组必须用 root 权限
普通用户无法更改自己的主属组，usermod -g 只能由 root 或具备 sudo 权限的用户执行。执行后，用户下次登录时才会生效（已登录会话中 id 显示仍为旧组，需重新登录或 newgrp 切换）。
-
usermod -g www dev_read：将用户dev_read的主属组（primary group）改为www - 主属组会写入
/etc/passwd第四字段（GID），同时清空该用户在/etc/group中作为成员的记录（除非是附加组） - 若目标组不存在，命令直接失败，需先用
groupadd www创建
usermod -G 添加/覆盖附加组（secondary groups）
用户可同时属于多个组，但只有一个主属组；其余都算附加组，用于权限叠加。注意 -G 是“覆盖式写入”，不是追加。
-
usermod -G www,ftp dev_read：把dev_read的附加组设为www和ftp，原附加组全部丢失 - 要保留原有附加组并新增一个，得先查出来：
groups dev_read，再拼接完整列表重设 - 附加组信息存在
/etc/group文件里，每行末尾的用户名列表就是成员
chgrp 对文件目录改属组不等于改用户属组
新手常混淆：改文件属组（chgrp）和改用户属组（usermod）是两件事。前者影响文件访问权限，后者影响用户身份上下文。
-
chgrp -R www /var/www/html：递归把目录及内容的属组设为www，但dev_read用户本身还是原来的组 - 只有当用户是目标组成员（主属组或附加组），且文件权限含
g+rwx，才能据此获得访问权 - 常见误操作：只改了文件属组却没把用户加进该组，结果权限仍不生效
验证修改是否真正生效的三个检查点
别只信 usermod 命令没报错——它不校验逻辑一致性，很多问题要到实际访问时才暴露。
- 查
/etc/passwd：确认第四字段 GID 已更新，对应getent group <gid></gid>能查到组名 - 查
/etc/group：确认用户是否出现在目标组的成员列表末尾（主属组不会列在这里，但附加组必须有） - 实测权限：切到该用户（
su - dev_read），运行id看输出，再尝试读写目标目录下的文件
改用户属组这事看着简单，真正卡住人的地方往往不在命令本身，而在「用户到底属于哪些组」和「文件到底认哪个组」之间的映射关系没理清。尤其要注意 -g 和 -G 的语义差异、以及 id 输出里 groups 列表的顺序——Linux 权限检查时，只认第一个匹配的组，不保证按字母或创建顺序排。
