飞翔的十号上周帮一家创业公司做服务器规范时，运维小哥问了我一句：“我们团队十几个人，每个人都要访问测试服务器的不同目录。我现在每个人单独给权限，每次新同事入职我都要忙半天，有没有更省事的办法？”我告诉他：把用户和组管理搞清楚，这事半小时就能解决。后来我帮他梳理了一遍用户与组的规划，给了他一套基于组的授权方案，问题直接归零。
用户与组管理，是Linux系统里最基础、也最容易被忽视的一环。它解决的核心问题就三件事：第一，让多个用户能安全地共享一台机器；第二，让不同角色的人能访问不同范围的资源；第三，让系统能追踪“谁在什么时候做了什么”。这篇内容适合刚接触Linux的运维新人，也适合那些已经用了很久、但一直靠“复制粘贴命令”过日子、没有系统梳理过这套机制的人。我会从概念讲到实操，把常见坑一并踩给你看。
1. 用户与组管理到底在管什么：概念拆解与设计思路
1.1 用户、组、权限三者是怎么咬合在一起的
很多人第一次接触用户与组管理时，总觉得这是两个独立的概念：用户就是“谁登录了系统”，组就是“把一群人划到一起”。但实际上，用户和组在Linux设计里是一套配合使用的权限控制体系，单独拎出来任何一个都不完整。
核心逻辑可以这么理解：用户是身份的载体，代表着“谁”在操作系统；组是身份的集合，代表着“哪些人属于同一类”；而文件系统上的权限（读、写、执行）是这套体系最终要保护的东西。三者之间的咬合关系，可以简化为两条线：
- 用户通过组成员关系，获得组对应的权限。
- 文件通过“属主、属组、其他”三组权限位，限定不同身份能做什么。
举个例子，你有一个数据库备份目录 /data/backup，你希望只有运维组的成员能读写，其他用户一律禁止。在Linux里，你只需要把目录属组设为 ops，权限设为 770，再把所有运维人员加入 ops 组，一切就自动生效了。这里面没有任何一条“单独给某个用户授权”的操作，但效果却覆盖了所有组内成员。
从设计角度看，这就是Linux权限模型的精髓：权限绑定在组上，用户通过加入组来继承权限。理解这一点之后，你就会明白为什么很多老运维反复强调“不要直接给用户授权，要授权给组”，因为这能让你在人员变动时只需要调整组成员关系，而不需要跑到每个文件目录上去改属主属组。
1.2 为什么“先用组、后用用户”是标准工程玩法
我在实际项目里见过太多次类似的混乱局面：新同事入职，管理员直接在 /etc/passwd 里复制一行配置，手动改一下用户ID（UID），然后把这个用户加到某几个目录的ACL里。看起来能用，但等人员一多、权限一复杂，问题就全出来了。
最典型的场景是：某天公司调整组织架构，原来A部门的10个人中有3个人调去了B部门。如果你是“按用户授权”的思路，你需要找到这3个人涉及的每一个文件、每个目录，逐一调整他们的权限。如果系统里有上百个目录和脚本，这活基本没法干完。反过来，如果当初你只维护了 dept_a 和 dept_b 两个组，把所有目录的权限绑定在组上，那么调整组织架构时你只需要把3个用户的 gid（主组）或附加组从A改成B，就全部搞定了。
正是基于这种效率差异，业内才总结出了一套标准工程玩法：先规划组，再创建用户，然后把权限绑定到组上。具体来说，可以分四步：
- 根据部门、项目或职责划分好需要哪些组（例如
ops、dev、qa、data）。 - 规划好每个组对应的目录范围，以及目录的权限策略（例如
750还是770）。 - 创建用户时，把主组或附加组直接指到对应的组上。
- 严格约束“直接改文件属主/属组”的操作，尽量都通过组来统一管理。
这个思路在十几个人的小团队和几百人规模的企业里都适用，差别只在于组的粒度。小团队可能只需要两三个组，大企业则往往结合目录服务统一管理，但底层逻辑完全一致。
1.3 系统里用户与组的三大“账本”：passwd、shadow、group
要把用户与组管理真正吃透，你必须知道系统里记录这些信息的账本文件。Linux下最核心的三个文件是 /etc/passwd、/etc/shadow 和 /etc/group。
/etc/passwd 里每一行就是一个用户账户，格式是“用户名:x:UID:GID:注释:家目录:登录Shell”，字段之间用冒号分隔。这里有一个容易让新人疑惑的点：为什么口令字段是 x？因为现代Linux系统早就不把密码明文或哈希放在这个文件里了，x 只是一个占位符，真正的密码哈希被挪到了 /etc/shadow 文件里。这样设计的安全性考量很直接：/etc/passwd 的读取权限是所有人可读的，因为很多程序需要查询用户名和UID的对应关系；而 /etc/shadow 的权限被严格限制为只有root能读写，从而避免普通用户拿到密码哈希去做离线破解。
/etc/group 的格式和 passwd 类似：“组名:x:GID:组成员列表”。第四列是附加成员列表，用逗号分隔。要注意的是，这里只记录“把该组作为附加组”的用户，主组（也就是用户在 passwd 里 gid 字段指定的组）不需要在这里重复列出。
还有一类比较容易忽略的账本：UID和GID的可复用范围。普通用户创建时，系统通常会分配1000以上的UID；而0是root的UID。很多系统服务（如 sshd、nginx）也会有自己的系统账户，这类账户的UID一般在1-999之间。规划用户时，我建议尽量不要去复用那些已经使用过的UID，尤其是不要把普通用户直接绑定到0号UID或让普通账号的UID等于0，否则等于给了它root级别的权限，这种写进教科书里的“后门陷阱”在真实环境中仍然偶有出现。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 用户管理的核心实操：创建、修改、删除一把梭
2.1 useradd 创建用户的常用参数与细节
创建用户的命令是 useradd，但它在不同发行版上的默认行为有一点差异。在CentOS/RHEL系列上，useradd 默认不会自动创建家目录，需要额外加 -m 参数；而在Ubuntu/Debian系列上，默认往往会自动创建家目录。这个差异曾经坑过不少人，所以我建议你创建用户时把关键参数显式写清楚，不要依赖系统默认。
一个比较稳妥的创建命令长这样：
bash复制useradd -m -d /home/zhaoli -u 1050 -g ops -G dev -s /bin/bash -c "Zhao Li" zhaoli
逐个解释一下：
-m：强制创建家目录，目录位置由-d或系统默认规则决定。-d：指定家目录路径，默认情况下是/home/用户名。如果项目特殊，比如开发环境可能需要把家目录放在/data/home下，就要显式指定。-u：手动指定UID。在需要保持多台机器用户UID一致时很有用，比如配合NFS共享目录场景，如果两台机器上同一个用户的UID不一样，访问共享文件时就会出现“明明是我，但系统不认我”的怪问题。-g：指定主组，主组可以用组名，也可以用GID。这个字段对应passwd文件里的第四个字段。-G：指定附加组，多个组用逗号分隔。附加组记录了用户额外关联的组身份。-s：指定登录Shell。单纯做服务运行或FTP访问的账号，可以直接设为/sbin/nologin，避免被用于交互式登录。-c：注释信息，通常写真实姓名或用途说明，方便后面的人能看懂这个账号是干什么的。
创建完用户后，还要设置密码：
bash复制passwd zhaoli
执行后系统会提示你输入两次新密码。如果想让用户首次登录时必须自己改密码，可以用 chage -d 0 zhaoli，这样用户第一次登录就会被强制要求修改密码，适合给外包人员或临时访客开通账号的场景。
2.2 usermod 修改用户信息与锁定/解锁
用户创建之后不可能一成不变，改信息的时候用的就是 usermod。它的常用参数跟 useradd 高度重合：-g 改主组，-G 改附加组，-s 改Shell，-l 改用户名，-d 改家目录，-L 锁定账号，-U 解锁账号。
这里有一个高频操作场景：把用户从旧组挪到新组。如果直接执行：
bash复制usermod -G newgroup user1
那么这个用户的附加组会变成只有 newgroup，之前所有的附加组都被清空了。如果你希望保留原有附加组再追加新组，需要把原有附加组完整列出来，例如：
bash复制usermod -G ops,dev,newgroup user1
这个细节非常容易被忽略，但实际影响很大。我见过不止一次事故：管理员想把用户加入一个新项目组，结果顺手把用户从原来的权限组里“带”了出来，该用户第二天无法访问日常业务目录，工单直接打到运维这边。所以我的习惯是：执行 usermod -G 之前，先查看一下用户当前的组信息，再做增量修改。
查看用户组信息的命令很简单：
bash复制id user1
groups user1
id 会显示UID、主组GID以及所有附加组，groups 输出的是可直接阅读的组名列表。
2.3 userdel 删除用户时的坑与后事处理
删除用户的命令是 userdel，但我不建议直接裸执行。裸执行时，系统只会删除 /etc/passwd、/etc/shadow 里的账户记录，家目录和用户邮件的文件仍然留在磁盘上，时间长了会积累大量“无主文件”。配合 -r 参数可以把家目录和 /var/mail/用户名 邮件目录一并清理：
bash复制userdel -r user1
不过更稳妥的做法是先在删除之前把用户的数据备份出来，因为 -r 会删除家目录里所有数据，这个动作不可逆。如果只是暂时停用账号，建议不要删除，而是用 usermod -L 锁定账号，或者用 usermod -s /sbin/nologin 禁止登录，等确认相关数据和权限都处理完了再执行删除。
删除用户之后还有一个经常被忽略的“后事”：清理这个用户在系统中遗留的其他文件。比如他在 /tmp 下的临时文件、他启动的定时任务、他拥有的某个服务进程，都可能因为账号被删除而变成“孤儿”。查找这类文件可以用：
bash复制find / -nouser 2>/dev/null
-nouser 参数会列出所有属主在系统中已不存在的文件，处理完这些文件后，再考虑彻底删除账号，才是一个完整闭环。
3. 组管理的实操流程：建组、授权、验证一条龙
3.1 groupadd 创建组与 groupmod/groupdel 的日常用法
创建组最简单的方式是：
bash复制groupadd gx_ops
如果需要指定GID，就加 -g 参数：
bash复制groupadd -g 1500 gx_qa
修改组名用 groupmod -n：
bash复制groupmod -n qa_new gx_qa
删除组用 groupdel。这里有一个常见的限制：如果某个组是一个或多个用户的主组，groupdel 会直接报错，系统不允许删除这种组。你需要先把用户的主组改到其他组上，才能继续删除操作。
日常组管理里最常用的操作其实是往组里添加用户。有两种方式，一种是用 usermod -G，另一种是 gpasswd -a，效果类似：
bash复制gpasswd -a user1 gx_ops
相对于 usermod -G 需要列出完整附加组列表，gpasswd -a 是纯追加式的，不会干扰用户已有的附加组配置。所以我个人更推荐在“往已有组里加人”的场景下用 gpasswd -a，风险更小。
3.2 用组做目录权限控制的完整案例
光说概念没什么感觉，这里给一个完整的实操案例。假设服务器上有一个共享项目目录 /srv/project_a：
- 创建项目组和用户：
bash复制groupadd project_a
useradd -m -s /bin/bash -g project_a zhangwei
useradd -m -s /bin/bash -g project_a lisi
useradd -m -s /bin/bash -g ops wangwu
这里 zhangwei 和 lisi 的主组都是 project_a，wangwu 的主组是 ops。
- 创建目录并设置属组：
bash复制mkdir /srv/project_a
chown root:project_a /srv/project_a
chmod 770 /srv/project_a
chown root:project_a 表示目录的属主是root，属组是 project_a。chmod 770 表示属主和属组都有完整读写执行权限，其他用户一律无权限。
- 验证效果：
- 用
zhangwei登录，能进入/srv/project_a并创建文件。 - 用
wangwu登录，会被拒绝，因为他不在project_a组里。 - 如果
wangwu后续加入项目，只需执行：
bash复制gpasswd -a wangwu project_a
然后他重新登录一次，就能正常访问了。
这个案例里的关键点在于：权限只挂在目录和组上，流程清晰，之后新增任何人只需要一条 gpasswd 命令。
3.3 查看用户与组关系的几个高效命令
实际运维中你经常会遇到“这个用户到底在哪些组里”“这个组里到底有哪些人”这样的问题。查看方法比较固定：
- 查看用户属于哪些组：
id 用户名或groups 用户名 - 查看组里有哪些用户：
getent group 组名，或者直接grep 组名 /etc/group - 查看所有用户列表：
cut -d: -f1 /etc/passwd - 查看所有组列表：
cut -d: -f1 /etc/group
这里有个小技巧：getent group gx_ops 输出的第四列就是该组的附加成员列表，但如果某组的成员全都是主组用户，这里可能显示为空，因为主组成员在 /etc/passwd 里就已经通过GID关联上了。为了完整掌握组内成员，可以把 getent group 的结果和 /etc/passwd 里GID的字段结合起来看。写成一行命令：
bash复制awk -F: -v g=$(getent group gx_ops | cut -d: -f3) '{if($4==g) print $1}' /etc/passwd
这个命令的作用是：先拿到组的GID，再从 passwd 里把所有主组GID等于它的用户名打印出来。结合起来才能看到“主组+附加组”两个维度的完整成员列表。
4. 常见问题与排查技巧实录
4.1 登录失败类问题排查
用户突然登录不了，是最常见的运维求助。排查顺序基本是固定的：
第一，先看账号是否被锁定。执行 passwd -S 用户名 或 chage -l 用户名，如果状态里出现 L 或锁定标记，用 usermod -U 解锁。锁定状态经常发生在连续登录失败后，有些安全策略会自动锁掉账号。
第二，确认Shell是否合法。如果 /etc/passwd 里这个用户的Shell是 /sbin/nologin，那你当然登录不了，这可能是之前为了临时禁用故意设置的。
第三，验证密码是否正确。这个没法直接看，但可以通过 passwd 重新设置一次来排除密码损坏的问题。
第四，检查家目录和登录目录的权限。家目录权限如果被设置成 700 且属主不是该用户，或者 .ssh 目录权限不对，SSH登录时就会出现“密码正确但被拒绝”的现象。SSH对这种异常尤为敏感，.ssh 目录权限必须是 700，authorized_keys 文件权限必须是 600，稍微放开一点就可能被拒绝。
4.2 权限不生效的常见误区和排查方法
“我把用户加入组了，为什么他还是不能访问目录？”这个问题被问的频率极高。我通常先反问一句：你加完组之后，用户重新登录了吗？在早期Linux版本里，组的变更要重新登录才能生效，后来的版本通过 newgrp 命令可以临时切换主组，但绝大多数场景下用户都需要退出重新登录一次。如果你是用 su 切用户的话，建议完全退出会话后再登录，因为部分情况下 su 的会话不会刷新附加组信息。
另一个常见误区和目录权限本身有关。比如你要访问 /srv/project_a/sub，光有 sub 目录的权限不够，你还要对路径上的每一级目录都有 x（执行）权限，即 /srv 和 /srv/project_a 都要允许该用户通过。很多新人只盯着目标目录的权限，却忽略了父目录的权限限制。
还有一个容易被忽略的点：如果文件系统上启用了ACL，那么传统的 chmod 权限可能不是最终生效的依据。安装 acl 工具后，用 getfacl 可以查看完整ACL规则，排查时务必先确认有没有ACL在“暗中阻挠”。
4.3 误删用户后的恢复思路与教训
误删用户的事故，我见过不止一次。如果只是删除了账户但没删家目录，恢复的思路是：重新创建相同UID的用户，然后把家目录属主改回来。
假设原用户 zhangwei 的UID是1050，你不小心用 userdel 删掉了账号。这时你看 /home/zhangwei 还在，可以先重建用户：
bash复制useradd -m -u 1050 -g ops -s /bin/bash zhangwei
只要UID和原来一致，系统就会把这个家目录“认”回来。如果家目录属主显示成数字1050而不是用户名，就执行：
bash复制chown -R zhangwei:ops /home/zhangwei
这个恢复方案成立的前提是：原UID没有被其他用户占用。所以我一直强调，删除用户前先记录UID和GID，并且尽量不要频繁复用UID，一旦发生错误恢复就很有价值。
4.4 批量管理用户与组的小脚本
系统里用户数量一多，手动逐条操作容易出错。我自己在批量场景下最常用的思路，是结合一个简单的CSV文件和 for 循环脚本来批量创建用户。比如下面这个例子：
bash复制while IFS=, read -r username groupname shell; do
# 去掉首行表头
if [ "$username" = "username" ]; then continue; fi
# 创建一个组（如果已存在会报错，忽略即可）
groupadd "$groupname" 2>/dev/null || true
# 创建用户并设置主组
useradd -m -g "$groupname" -s "$shell" "$username"
done < users.csv
配合一个简单的 users.csv 文件，就能在几分钟内完成几十个用户的初始化：
code复制username,groupname,shell
zhangwei,ops,/bin/bash
lisi,dev,/bin/bash
wangwu,qa,/bin/bash
如果还需要批量设置初始密码，可以在循环里加一句：
bash复制echo "$username:初始密码" | chpasswd
这里要提醒的是，批量脚本执行前一定要先在测试环境跑一遍，确认CSV格式、组是否存在、用户是否重复，再将脚本放到生产机器上执行。我见过有人因为CSV里不小心混了一个空格，导致创建出一堆带空格的用户名，后期清理起来非常痛苦。
再补充一个批量“收权”的思路：当某个成员离职或调岗时，可以用 gpasswd -d 把他从附加组里移除：
bash复制gpasswd -d user1 gx_ops gx_dev
注意 gpasswd -d 一次只能移除一个附加组，所以多个组要写多遍，或者直接用 shell 循环处理。
用户与组管理这个主题，看起来只是几个命令的事，但真正深入之后会发现它牵扯到系统安全、权限模型、文件系统、账号生命周期管理多个层面。我自己的习惯是每搭建一套新环境，先做好组规划，再创建用户，之后所有权限调整都围绕组展开，极少直接动文件的属主。这套方法让我在处理人员变动和权限排查时省下了大量时间。
最后再分享一个小技巧：每周花五分钟跑一次 find / -nouser -o -nogroup 2>/dev/null，检查一下系统里有没有无主文件。出现这种东西通常意味着有用户被删但文件没清干净，或者有服务的属主配置错了。及时处理，能避免很多潜在地权限混乱。用户与组的管理没那么多高深技术，核心就是把账理清楚、把关系理顺，剩下的都是一遍遍的熟练工。