一台 Linux 服务器上塞着几十个账号有人要跑数据分析有人要部署 Web 服务还有测试环境要让外包协作更别提公司还配了一台 NAS 来存共享文件。如果你手动useradd一个个建账号不规划 UID不给共享目录做权限隔离前期一两个月还看不出来问题等人员一多、项目一多各种我能看到别人的目录NFS 挂载上来权限全乱删个离职账号结果文件全归了 root的糟心事就会接踵而来。这篇 SOP或者说经验贴解决的正是这件事多用户 Linux 服务器的账号开通流程怎么标准化权限隔离怎么做才不容易漏以及当后端有 NAS 时如何通过统一 UID 让 Linux 和 NAS 上的文件身份对齐。这些内容不深奥全是运维日常能直接落地的操作适合刚接手服务器管理的运维新人也适合给那些临时开个账号的同事当规范参考。1. 先想清楚再动手账号管理的目标和 UID 的意义1.1 一套账号 SOP 要解决哪些问题很多服务器刚装好的时候只有 root 一个账号管理员图省事谁要环境就直接给 root或者统一建一个admin账号让大家共用。这种做法的隐患不用我多说出了问题查不到是谁操作的权限也没有边界一个误删除可能把别人的目录也带走。所以账号管理的第一个目标就是身份可区分——每个使用者有独立账号行为才能被审计。第二个目标是权限可隔离。大家共用一台服务器各干各的、互不干扰是最低要求在这个基础之上才谈得上协作。隔离做得好不好不在于你是不是用了多复杂的工具而在于目录规划是否从第一天就配套上了。第三个目标是流程可复制。今天来了一个实习生明天走了一个外包如果每次开号都靠人工敲命令、凭记忆决定 UID 和目录权限那迟早会出岔子。把流程固化成 SOP 和脚本才是真正的稳定。1.2 UID/GID 到底管什么Linux 内核不认用户名它只认数字 ID。ls -l里显示的root root其实是 UID 0 和 GID 0 被翻译成了字符串。你创建一个用户zhangsan系统分配一个 UID比如 1001那么zhangsan创建出来的文件在磁盘上记录的 owner 就是 1001而不是名字。这里有一个很多新手容易忽略的坑用户名只是 UID 的显示标签。只要 UID 相同哪怕两台机器上的用户名不一样文件系统也认为它们是同一个身份。反过来也一样——如果两台机器上都有zhangsan但一台是 UID 1001另一台是 UID 1005那在 NFS 或 NAS 共享场景下文件权限就会错乱。所以统一 UID的本质是让用户在不同系统Linux 服务器、NAS、甚至其他 Linux 机器上拥有同一个数字身份。只要身份对齐权限系统就能正常工作。1.3 NAS 场景里的身份是怎么匹配的NAS 一般用两种协议对外提供共享NFS常用于 Linux和 SMB/CIFS常用于 Windows 和部分 Linux 挂载。NFS 在默认情况下就是靠 UID/GID 来判断身份客户端发来的请求里带着 UID服务端比对目录属主和权限位。如果客户端用户 UID 是 1001但 NAS 上文件的属主是 1005那即使两边用户名都叫zhangsanNAS 也不会认为这是同一个人照样拒绝写入。SMB 协议稍复杂会做 Windows SID 到 UNIX UID 的映射比如当前很多主流 NAS 系统允许你给某个 SMB 用户绑定一个 Linux 用户或者通过 AD 域来自动对应。但如果公司规模不大、没有 AD纯粹靠本地账号那么 NAS 管理界面里设置的属主 UID和 Linux 客户端账号的 UID 对不上就会出现我明明有权限却写不进去的怪问题。搞明白这一点前面说的账号开通 SOP就不再只是 Linux 单机的事而是要从服务器和 NAS 协同的角度统一规划。2. 从账号规划表开始把 useradd 变成一套可复制的标准流程2.1 第一步先建规划表别急着敲命令我见过太多人开通账号随手useradd一个用户系统自动分配一个 UID等到需要对接 NAS 时才发现这台服务器的 UID 已经像补丁一样叠了好几个段根本没法梳理。为了避免这种局面账号规划一定要先于操作。规划表至少包含这几列字段示例说明用户名zhangsan建议统一小写字母不用拼音全拼太长的形式可加上项目缩写用户组devops主组建议按项目或职能划分UID6001手动指定避开系统保留段家目录/data/home/zhangsan放到单独的数据分区避免和系统盘抢占空间登录 Shell/bin/bash特殊情况可设为 /usr/sbin/nologin有效期限2025-12-31外包或实习生账号建议加过期时间共享目录组>groupadd -g 6000 devops useradd -u 6001 -g devops -d /data/home/zhangsan -m -s /bin/bash \ -G>username,uid,gid,group,home,shell,expire,desc zhangsan,6001,6000,devops,/data/home/zhangsan,/bin/bash,2026-12-31,dev lisi,6002,6000,devops,/data/home/lisi,/bin/bash,2026-12-31,dev wangwu,6003,7000,ops,/data/home/wangwu,/bin/bash,2025-06-30,outsource对应的批量创建脚本Bash#!/bin/bash # open_accounts.sh # 用法: ./open_accounts.sh users.csv CSV_FILE$1 if [ ! -f $CSV_FILE ]; then echo usage: $0 users.csv exit 1 fi # 跳过表头 tail -n 2 $CSV_FILE | while IFS, read -r username uid gid group home shell expire desc; do # 判断组是否存在不存在则创建 if ! getent group $group /dev/null 21; then groupadd -g $gid $group echo [GROUP] created group: $group gid$gid fi # 判断用户是否已存在 if id $username /dev/null 21; then echo [SKIP] user exists: $username continue fi useradd -u $uid -g $group -d $home -m -s $shell \ -e $expire -c $desc $username echo [USER] created: $username uid$uid group$group home$home # 创建附加共享组需要单独处理示例里省略 done echo done.脚本里的getent group是检查组是否存在的通用方式比直接读/etc/group更标准。如果用户已经存在则跳过避免重复创建报错。小提示批量创建后还要做一次复核也就是把所有新账号的id、家目录权限、组成员关系都打印出来看一眼。这一步建议写进 SOP别省略。2.4 密钥登录与首次登录检查账号建好后密码策略要定清楚。如果公司安全要求高建议直接禁用密码登录改为 SSH 密钥。做法是把用户的公钥写入/data/home/zhangsan/.ssh/authorized_keys然后确保/etc/ssh/sshd_config中PasswordAuthentication no。但要注意全部禁用密码前必须确认所有人都有密钥否则会把用户锁在门外。家目录权限也需要检查。useradd -m创建的家目录默认权限是 755即属主可读写执行同组和其他人可读可进入。对个人私密数据来说755 太宽松我更倾向于改成 700chown zhangsan:devops /data/home/zhangsan chmod 700 /data/home/zhangsan首次登录后用户可以自行发挥但管理员在发号时要把密码修改要求或密钥登记流程说清楚否则后续又是一堆弱密码和共享密钥。3. 权限隔离实操目录规划、特殊权限和 ACL 兜底3.1 目录结构先定好后面才不乱账号建好了不等于隔离做好了。真正决定权限隔离成效的是目录结构设计和权限分配。我常用的结构如下/data ├── home/ # 用户家目录每人一个子目录 │ ├── zhangsan/ │ └── lisi/ ├── projects/ # 共享项目目录 │ ├── proj_a/ # 项目A组权限控制 │ └── proj_b/ ├── common/ # 全员可读的公共资料 └── archive/ # 归档区域一般只读在这里/data/home是私有区域权限 700只有属主自己能进/data/projects是团队协作区域每个项目一个组比如proj_a_dev/data/common是可读不可写的公共区/data/archive是历史归档默认只读。3.2 用组权限做协作隔离多人协作最基础的做法就是组权限。举个例子proj_a项目有三个开发和一个测试为了让他们能访问同一个目录并互相编辑文件可以建一个组proj_a_devgroupadd -g 8001 proj_a_dev usermod -a -G proj_a_dev zhangsan usermod -a -G proj_a_dev lisi mkdir -p /data/projects/proj_a chown root:proj_a_dev /data/projects/proj_a chmod 2770 /data/projects/proj_a2770这个权限码有两个特殊含义2是 setgid770是属主和组可读写执行其他用户无权限。setgid 的作用是目录下新建的文件自动继承目录的组而不是继承创建者的主组。没有 setgid 的话zhangsan在里面创建的文件会变成zhangsan:devops小组里的其他人比如lisi是另一个部门主组不是devops就改不了。加上 setgid 后文件属组自动变成proj_a_dev协作就顺畅了。3.3 umask、sticky 和 setgid 的配合umask 决定新建文件和目录的默认权限。系统默认常见的是 022也就是文件 644、目录 755。但如果是协作目录umask 022 可能导致同组其他人无法修改你新建的文件。更合适的是把umask 002加进用户的.bashrc让默认文件权限变成 664再配合 setgid协作就很流畅。还有 sticky bit就是权限码里的11777。它最经典的场景是/tmp所有人都能在里面创建文件但只有文件属主或 root能删除别人的文件。如果你有一个多人上传区希望人人能往里写但不能删别人的文件就在目录上设置 stickymkdir -p /data/common/upload chmod 1777 /data/common/upload这样upload目录里每个人都能创建文件但删除时只能删自己的避免误删事故。3.4 当组权限不够用时用 ACL 做精细兜底纯 rwx 权限的粒度比较粗只有属主、属组、其他三类。如果遇到张三能读李四能读写王五什么都看不到但他们都在同一个组里这类需求组权限就撑不住了。这时候用 ACLAccess Control List补一层。setfacl -m u:lisi:rwx /data/projects/proj_a setfacl -m u:wangwu:0 /data/projects/proj_asetfacl -m u:lisi:rwx给用户lisi单独加权限u:wangwu:0是明确禁止wangwu的访问。查看时用getfaclgetfacl /data/projects/proj_aACL 配置起来很灵活但别一开始就用它代替组权限原因有二一是组权限更直观ls -l一眼能看懂二是 ACL 多了之后排查继承关系和权限重叠会非常烧脑。我的一般原则是组权限做主干ACL 只用来处理例外。注意重要目录的权限变更记录建议用 shell history 或配置管理工具保存这样出了问题能快速回溯是哪一步改错了。4. NAS 统一 UID 场景让跨系统权限不再互相打架4.1 先看 NAS 端怎么识别身份如果你公司有一台 NAS 用于共享文件比如全员有一个公共盘、每个项目有一个共享文件夹那么 Linux 服务器上账号的 UID 就必须和 NAS 上的账号 UID 一致否则权限会解释得很扭曲。拿 NFS 共享为例服务器上zhangsan的 UID 是 6001NAS 上共享文件夹proj_a的属主设置成了 UID 6001 的账号那么zhangsan挂载 NFS 后进这个目录就有权限如果 NAS 上属主是 UID 6005那zhangsan进去就是其他人的文件读写受限。SMB 共享有时在 NAS 界面里看到的是用户名列表但底层映射到 Linux 时NAS 依然需要一个 UID 来确定属主。大批量的 NAS 产品都支持在用户管理里手动绑定或修改 UID只是默认是自动分配。所以统一 UID不仅是 Linux 侧的事NAS 侧也要同步。4.2 UID 规划表怎么落到 NAS建议做一张全局账号统一规划表里面包含 Linux 和 NAS 两边的账号信息用户名UID主组说明Linux 侧NAS 侧zhangsan6001devops研发已创建已创建lisi6002devops研发已创建已创建wangwu6003ops运维外包已创建已创建xiaoli6004fin财务待创建待创建每次新增人员先在表里占一个 UID然后 Linux 和 NAS 都按这个 UID 去建账号。NAS 端创建账号后到共享文件夹权限设置里指定这个 UID 的账号为属主或可读写成员。两边身份对齐才算完成闭环。4.3 已有系统怎么对齐 UID最理想的情况是新项目从零开始就统一规划但实操中往往有存量系统。比如 Linux 上zhangsan已经建好UID 是 10080而 NAS 上同一人的账号 UID 是 6001文件权限已经开始乱了。这时候做 UID 对齐要谨慎步骤是告诉zhangsan在某个时间窗口内不要操作文件最好退出登录。在 Linux 上用usermod -u 6001 zhangsan修改 UID。修改zhangsan家目录和所有属于它的文件的属主 UIDusermod -u 6001 zhangsan chown -R --from10080 6001 /data/home/zhangsan find /data -user 10080 -exec chown 6001 {} \;如果系统里有 cron 任务、服务等以旧 UID 运行的也要一并处理。通知用户重新登录验证重点检查是否还能访问原有文件、能否正常挂载 NAS。usermod -u修改 UID 后文件系统里旧 UID 的所有者不会自动跟着变必须配合chown。这个顺序不能反否则容易出现短暂的文件属主不一致。4.4 批量对齐的参考脚本存量系统往往不止一个用户需要对齐下面是一个批量对齐脚本的简化思路#!/bin/bash # align_uid.sh # 格式: old_uid:new_uid:username while IFS: read -r old_uid new_uid username; do if id $username /dev/null 21; then # 先修改用户 UID usermod -u $new_uid $username # 把该用户原先所属的文件改成新 UID find /data -user $old_uid -exec chown $new_uid {} \; 2/dev/null echo [OK] $username: $old_uid - $new_uid else echo [SKIP] user not exists: $username fi done uid_map.txt注意find前面只框定了/data如果文件散落在/home等其他路径需要按实际情况调整范围。而且执行时建议一台台服务器分别跑别在一台服务器上同时跑多个任务免得路径重叠产生冲突。4.5 验证和日常巡检对齐之后至少要验证三件事id输出里的 UID 是否与规划一致。在 NAS 共享目录里创建测试文件看属主是否正确显示为规划的用户。用另一个用户尝试访问确认权限隔离仍然生效。日常巡检可以写一个简单脚本定期比对服务器上的 UID 列表和 NAS 导出的用户列表发现不一致就告警。如果没有监控系统哪怕一个月手动比对一次也比永远不知道强。5. 高频问题排查实录这些坑我真的踩过5.1 SSH 登录失败但不是密码错最常见的原因是家目录或~/.ssh权限太宽松。OpenSSH 为了保护私钥对权限要求比较苛刻家目录不能对其他人可写.ssh目录建议 700authorized_keys建议 600。如果调试半天觉得密钥没问题就用下面两条命令先收紧chmod 700 /data/home/zhangsan/.ssh chmod 600 /data/home/zhangsan/.ssh/authorized_keys chmod 700 /data/home/zhangsan如果是第一次登录卡在输入密码但总被拒绝可以看/var/log/secure或/var/log/auth.log。有时候是/etc/ssh/sshd_config里的AllowUsers把新账号给过滤掉了或者是DenyUsers里正好有该用户名。这个特别容易漏因为你创建用户时系统不会检查 SSH 配置文件。5.2 NFS 或 NAS 里文件权限错乱这个问题的第一个排查方向就是 UID 不一致。在 NAS 挂载点执行ls -l看文件属主显示的数字或名字和预期是否一致。如果显示成了数字而不是名字说明本机/etc/passwd里没有这个 UID 对应的账号信息或者 UID 与 NAS 侧不一致。这时候回到规划表确认两边的 UID不要只看用户名。另一个常见原因是 NAS 的 SMB 共享开启了权限继承或ACL 覆盖把文件属主改成了everyone或某个映射账号。这种场景下你需要先到 NAS 端关闭权限继承改为手动指定否则 Linux 侧怎么折腾都没用。5.3 用户离职了文件该何去何从删除用户的常规操作是userdel -r zhangsan-r会删掉家目录和邮件池。但实际工作中我从不轻易加-r因为用户名下可能有/data/projects里的文件删了家目录之后那些散落文件会变成 UID 数字的孤儿文件。更稳妥的流程是usermod -L zhangsan锁住密码让账号无法登录。把/data/home/zhangsan归档或移交给直属领导指定的人。找出该用户所有的文件find /data -user 6001 -ls。与业务方确认文件归属后再chown给接手人或者归档到/data/archive。最后确认无文件残留再userdel zhangsan。这样虽然慢一点但不会导致数据无主。如果急着删号又没归档以后找回文件要命。5.4 重复创建账号导致的 UID 冲突批量脚本如果没做存在性检查重复执行可能报useradd: user zhangsan already exists。这只是小问题更严重的是你手动指定 UID 时和已有用户冲突useradd -u 6001 zhangsan # 如果 6001 已被占用会报错所以批量脚本里id检查是必须的。如果真要修改已有账号的 UID用usermod -u并且记得处理文件归属。还有一种隐蔽情况/etc/passwd里没有冲突但/etc/group里某个组的 GID 已经占用了这个数字。groupadd时也一样要先getent group检查。5.5 排查技巧速查表症状首先检查什么修复思路SSH 密钥登录被拒家目录、.ssh权限收紧权限检查sshd_config的 AllowUsers用户能登录但进不了共享目录目录组是否包含该用户setgid 是否设置用usermod -a -G加入对应组NAS 挂载后看到数字属主UID 映射不一致对齐规划表中的 UID清空客户端缓存目录里新建文件组不对父目录 setgid 是否设置chmod gs目录用户删不掉提示用户正忙有进程以该用户运行中先pkill -u 用户名或迁移进程再删除权限怎么改都只读是不是有 ACL 优先级高于 chmod用getfacl查看 ACL调整或删除写在最后账号开通和权限隔离这些事听起来简单但真正到了几十台服务器、几百个账号、背后还挂着 NAS 的规模每一步不按规则走都会变成隐性的技术债。我个人经验是规范的 UID 规划表比任何复杂的权限工具都重要因为只要身份数字统一了后面所有权限系统的矛盾和误解都会少一大半。更实际一句话宁可多花十分钟规划 UID也不要在出问题之后花一整天排查为什么用户名一样但权限不对。把账号流程沉淀成 SOP无论是新建账号还是迁移系统都能省下整个团队的时间。