Linux权限管理与磁盘操作实战：从故障排查到数据迁移

去年有段时间，我刚接手一台跑业务的Linux服务器，立刻就被权限管理和磁盘操作两件事同时上了一课。登录进去想查一个应用日志，发现日志目录进不去，提示Permission denied；换root去看，原来整个目录的拥有者是uid 1003，但系统里压根没建这个用户。再随手敲一下df -h，数据盘用量已经97%，最要命的是日志里已经开始飘No space left on device。一个权限问题挡住了排查路径，一个磁盘问题随时可能让服务停摆。那阵子我几乎是边翻命令手册边处理，踩的坑比过去半年写代码时加起来都多。

这篇内容我打算按真实处理逻辑讲一遍，把一个运维人员实际会遇到的权限链路和磁盘操作串起来讲。适合刚入门但不想死背命令的Linux新手，也适合准备面试、想系统串一遍权限和磁盘考点的人。我不会按教科书的方式分开讲“什么是权限”“什么是磁盘”，而是直接说：遇到某类故障，你应该先看哪里、为什么要这样处理，看完你就能自己上手折腾了。

1. 权限和磁盘从来不是两门课：一次接手旧服务器的警醒

1.1 工作目录无法访问，df却显示磁盘满了

那天我遇到的情况非常典型：应用日志目录的属主是一个不存在的uid，普通账号无法读取，等我切到root去看，又发现应用写日志报“磁盘满”。查了一圈才知道，保留了一堆旧日志的目录挂在另一个分区下，而这个分区的权限只对某个老账号开放，老账号早被删了，数据盘却一直没人清理。

这其实揭示了一个非常关键的运维常识：权限系统和磁盘系统在故障现场往往是叠在一起的。目录权限不对，你就进不去；即使进去了，没权限你也删不了大文件；就算删了，如果进程还开着文件句柄，磁盘空间照样不会释放。你只懂chmod而不懂文件句柄，或者只懂df而不懂uid映射，都会被同一个故障卡死。

1.2 我更在意的是“权限失控”和“磁盘失控”的交叉影响

后来我在日常巡检里慢慢形成一套判断顺序：先看服务能不能访问文件，再看磁盘空间是否充足。因为很多时候程序报Permission denied，第一反应是权限问题，但如果你拉一下df -h，发现磁盘已经100%，有些服务会创建临时文件或锁文件失败，报错也可能长得像权限不足。

另一个交叉点是挂载。很多服务器把数据盘挂载在/home或/data下面，如果挂载点在系统启动时没挂上，程序就会改写到挂载点目录本身对应的根分区空间里，导致根分区悄悄被写满。而/home目录如果权限设置过宽，任何普通用户都能进来放一堆文件，最后磁盘满了你都不知道是谁干的。所以权限和磁盘不是两门独立的Linux课程，它们是在同一台服务器上共生的两个维度。

这个章节作为引子，接下来我把权限链路完整过一遍，再进入磁盘操作。

2. 用户与组：权限这条链路上的一切从“人”开始

2.1 别猜useradd的行为：显式指定家目录和shell

很多新手第一次在Linux建用户，执行useradd zhangsan，然后马上su - zhangsan，结果发现家目录不存在，shell也不对。原因很简单：不同发行版的useradd默认行为不一样。CentOS/RHEL系列通常会自动创建家目录，但Ubuntu/Debian上单纯执行useradd经常不会给你建/home/zhangsan。保险做法是创建时把参数写清楚：

bash复制useradd -m -d /home/zhangsan -s /bin/bash zhangsan

参数含义不复杂：-m表示创建家目录，-d指定家目录路径，-s指定登录shell。可能有人觉得多此一举，但如果你在写自动化脚本，这一步不写清楚，后面所有基于/home/用户的部署步骤都会翻车。

建好用户后要设密码：

bash复制passwd zhangsan

如果是在脚本里批量改密码，可以这样配合管道使用，但要注意命令历史里会留下明文密码。生产环境更推荐先用openssl passwd -6生成加密串，再写到chpasswd里。

2.2 账户配置文件的字段与修改原则

用户和组最终都落在四个文件里：/etc/passwd、/etc/shadow、/etc/group、/etc/gshadow。我不建议你直接去改这些文件，但必须看得懂，因为排查问题时你会频繁和它们打交道。

以/etc/passwd这一行为例：

text复制zhangsan:x:1001:1001:Zhang San:/home/zhangsan:/bin/bash

含义依次是：用户名、密码占位符、uid、gid、注释信息、家目录、登录shell。/etc/shadow里保存的是加密后的密码和过期策略，普通用户可以读/etc/passwd，但绝不能读/etc/shadow，这就是权限设计的基本分层。

修改用户信息我习惯用usermod而不是直接编辑文件。比如把zhangsan的家目录迁移到新分区，或想让他的uid和某台机器保持一致，都用usermod加对应参数。

bash复制usermod -d /data/home/zhangsan -m zhangsan

-d配合-m会把原家目录内容移动到新位置。这种“先查文件，再用命令修改”的习惯，能有效避免手误。

2.3 usermod -G和-aG：一个毁掉附加组的经典错误

把用户加到附加组，常见写法是usermod -G docker zhangsan。这个命令单独执行没有大问题，但它会重置用户的附加组列表为“只有docker”。如果zhangsan本来还在wheel组里，执行完这条命令，他就被悄悄从wheel组踢出去了。等到他需要用sudo时才发现权限没了，而你根本想不起什么时候踢的。

正确写法是加一个-a参数：

bash复制usermod -aG docker zhangsan

-a表示追加，-G指定组。我见过不止一个同事因为漏了-a，把所有普通用户都踢出了sudo组，只能重启进单用户模式修复。所以再强调一次：涉及修改用户附加组时，-aG是默认选项，只有当你明确想重置附加组列表时才单独用-G。

删除用户同样不能含糊。userdel zhangsan只删用户，不删家目录和邮件池；userdel -r zhangsan连家目录一起删。如果是有数据留存需求的账号，千万别加-r。我一般会先检查用户的家目录里有没有业务数据，再决定要不要完整清理。

3. 常规文件权限的三层拆解：从ls -l到数字权限

3.1 rwx在文件与目录上是两种“语义”

ls -l输出的第一列权限位很多人都会背：rwxr-xr-x，三个一组，分别是属主、属组、其他人。但真正理解文件与目录权限差异的人，往往要在生产环境踩过坑后才明白。同一组rwx，落在文件和目录上含义完全不同。

对文件来说，r是读内容，w是修改内容，x是执行。但要注意：能否删除这个文件，取决于它所在目录的写权限，而不是文件自身的写权限。所以一个644的文件放在一个777的目录里，任何能进目录的人都能把它删掉。

对目录来说，r是能列出目录里的文件名，x是能进入目录并访问其中文件的元数据。如果目录只有r没有x，你执行ls能看到一堆名字，但拿不到文件类型、大小等详细信息，访问起来非常别扭。w则决定你能否在目录里新建或删除文件。所以一个可用的工作目录，通常至少需要r-x；需要往里写文件的共享目录，才配置成rwx。

这里可以总结一句话：目录的x是“通行证”，没有它，r和w都发挥不出来。访问某个深层路径时，路径上每一层目录都需要执行权限，少一层都会提示Permission denied。

3.2 umask决定了你新建文件的默认权限

很多新手奇怪：为什么新建文件默认是644而不是666？为什么新建目录默认是755而不是777？这背后是umask在起作用。

文件创建时的权限计算可以粗略理解为：0666 & ~umask，目录则是0777 & ~umask。系统典型的umask值是0022，它把组和其他人的写权限去掉，所以文件变成0644，目录变成0755。

如果服务器上需要让同组用户协作，经常会把umask改成0002，这样新建文件自动变成0664，目录变成0775，组内用户可以读写。我帮团队配置共享目录时，通常会要求开发者在.bashrc或项目启动脚本里明确设置umask 0002，避免每个人手动去chmod。

查看当前值很简单：

bash复制umask

临时修改就是umask 0002，永久修改需要写到用户的shell配置里。这个默认值设计得非常精巧，系统不是让你每个文件都手动改权限，而是通过一个初始屏蔽位帮你避开了绝大多数“不该默认放开写权限”的场景。

3.3 chown/chmod实战：先改属主还是先给权限

部署Nginx或Java应用时，常见需求是把某个目录交给应用账号管理。很多人上来就chmod -R 777 /data/app，这省事但危险。我更推荐先把属主和属组改对，再精细化分配权限。

bash复制chown -R appuser:appgroup /data/app
chmod -R u=rwX,g=rX,o= /data/app

注意chmod里的X大写，它表示“仅当目标是目录或已有执行权限时才赋予执行权限”。对文件来说，如果本来不是可执行程序，就不会被错误地加上执行权限；对目录来说，一定会被加上执行权限，保证可进入。这样一条命令就能把普通文件和目录的执行权限区分开，避免一个目录下面所有脚本文件都变成可执行状态。

还有个实操经验：如果要保留目录结构但只改用户，可以用chown --reference来参照别的目录，也可以配合find按需修改，而不是对全量目录层层搜索。例如要把某个目录下所有子目录设为755、普通文件设为644：

bash复制find /data/app -type d -exec chmod 755 {} \;
find /data/app -type f -exec chmod 644 {} \;

这样做比chmod -R更安全，尤其是目录里混着配置文件、脚本和静态资源时。

4. 特殊权限位、ACL与sudo授权：权限管理的进阶层

4.1 suid的经典场景：普通用户为什么能改自己的密码

如果你看过/usr/bin/passwd的权限，会发现它长这样：

bash复制-rwsr-xr-x. 1 root root 33600 某日期 /usr/bin/passwd

属主的执行权限位不是x而是s，这就是setuid位。s的含义是：普通用户执行这个程序时，会临时以文件属主root的身份运行。为什么要这样设计？因为修改密码需要写/etc/shadow，而/etc/shadow只有root能读，普通用户应该没有权限直接读写它。但系统又允许普通用户改自己的密码，于是提供一小段经过安全审计的程序passwd，通过setuid让它在运行期间获得root身份，只做“改密码”这一个受限操作。

对这个机制我的建议很简单：非必要不要在生产环境给任何自定义脚本或二进制加setuid。它意味着任何能执行这条命令的用户，都可能拿到比你预期更高的权限。如果某个程序确实需要提权，优先考虑sudo白名单，而不是chmod u+s。

排查系统里哪些文件带setuid，可以执行：

bash复制find / -perm -4000 -type f 2>/dev/null

看到结果后逐个确认是否合法。常见的安全扫描也做这件事。

4.2 setgid与sticky bit：共享目录的安全性设计

团队协作时，多个用户需要往同一个目录写文件。如果目录的属组是project，用户都属于这个组，那么目录权限设为2775，即带setgid的rwxrwsr-x，效果是所有在这个目录下新建的文件，其属组自动继承目录的属组，而不是创建者自己的主组。这个特性非常有用。如果不设置setgid，用户A创建的文件属组是A，用户B即使同组也可能因为文件属组不一致，无法按组权限协作。

再看/tmp的权限：

bash复制drwxrwxrwt. 20 root root 某日期 /tmp

最后一位t是sticky bit。它的作用是在一个777的共享目录里，只有文件属主、目录属主或root能删除文件，其他人即使有目录写权限也删不掉你的文件。如果没有sticky bit，/tmp早就被互相删除文件搞得乱七八糟了。

设置特殊权限位时，我强烈建议用符号模式，可读性远高于数字模式：

bash复制chmod g+s /data/project
chmod +t /tmp

如果非要用数字模式，setuid是4、setgid是2、sticky是1，放在数字权限最前面，比如4755、2770、1777。顺序和含义都容易记混，所以在维护脚本里我尽量写清楚符号和注释。

4.3 ACL：不建组也能给第三人精准授权

普通的u/go权限只能把用户分成“属主、属组、其他人”三类。实际运维中经常遇到这种情况：一个目录归web团队管，但测试团队的某个特定账号也要能读一部分文件，我不想为了一个人新建一个组，更不想把目录权限改成777。这时候就需要ACL，访问控制列表。

先给文件或目录增加一条ACL：

bash复制setfacl -m u:testuser:r-- /data/web/config.ini

查看时用getfacl，能看到多了这样一行：

text复制user:testuser:r--

当你执行ls -l时，会发现文件权限位末尾多了一个+，就代表该文件或目录带ACL。如果想给某个目录设置默认ACL，让以后新建的文件都自动给某个用户授权，可以这样写：

bash复制setfacl -m d:u:testuser:r-- /data/web/

这里的d:表示default，只对目录生效。之后在该目录下新建的文件，都会自动带上给testuser的读取权限。

我踩过的一个坑是：ACL里的mask会限制命名用户和命名组的最大权限。如果你给某用户设了rwx，但mask是r--，实际生效只有r--。所以调试ACL时，看到effective:r--就要意识到是mask在起作用，不是规则没生效。

4.4 sudo提权策略：比直接切root更安全的工作方式

热搜词里经常出现“linux提权”，访谈里也常问“怎样安全提权”。我的答案一直很明确：能用sudo解决的问题，不要用su切root。

sudo的设计核心是最小授权。你可以在/etc/sudoers里规定某个用户只能执行哪几条命令。比如让运维新人只能重启Nginx和查看系统日志：

bash复制opsuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /bin/journalctl

编辑sudoers必须用visudo命令，不要直接改文件，因为visudo会做语法检查。如果你不小心写坏了，sudo会失效，而你又恰好已经退出了当前root会话，那就只能靠物理机或控制台进单用户模式修复，相当痛苦。

生产环境我更推荐的做法是：

• 禁止root直接SSH登录，修改/etc/ssh/sshd_config里的PermitRootLogin no。
• 给管理员分配普通账号，再通过sudo提权。
• 关键命令尽量做白名单，不给sudo ALL这种全量权限给非核心人员。

这套思路在业务里还能延伸成基于角色的权限管理。简单理解，用户组就是角色，sudoers里的规则就是角色能执行的权限项。先把权限收敛到组上，再把用户加到组里，比挨个给用户配sudo规则清晰得多，也方便离职或转岗时统一回收。

5. 磁盘从裸盘到业务分区：我的一次完整操作记录

5.1 识别设备：lsblk与blkid能告诉你什么

新买一台服务器或者新加一块云硬盘时，很多人上来就fdisk /dev/sdb，结果对错设备。所以我第一步永远是先识别设备。

bash复制lsblk

这个命令会把磁盘、分区、挂载点以树状关系列出来。你会看到sda、sdb、nvme0n1这类设备名。云服务器上经常是vda、vdb，本地NVMe盘则是nvme0n1。接着用blkid看文件系统和UUID：

bash复制blkid

输出里的UUID非常关键，因为后面写/etc/fstab时，用UUID比用/dev/sdb1可靠得多。设备名可能因为插槽顺序、驱动加载顺序变化，但UUID不会。

我曾经遇到过一台机器重启后/dev/sdb和/dev/sdc互换的情况，如果fstab里写的是/dev/sdb1，开机后可能挂错盘。换成UUID后，这个隐患就消失了。

5.2 分区表与格式化：MBR、GPT、xfs和ext4怎么选

磁盘分区时首先要确定分区表类型。老式MBR对单块磁盘最大只能管理约2TB，超过2TB必须用GPT。新磁盘我基本无脑选GPT，因为现在GPT已经是UEFI时代的默认标准，兼容性和扩展性都更好。

创建分区可以用fdisk，对于GPT格式的大磁盘我常用gdisk或parted：

bash复制gdisk /dev/sdb

进入交互界面后，输入n新建分区，选择分区号、起始扇区和结束扇区。扇区对齐问题现代工具基本自动处理好了，使用默认起始位置即可，不需要手动调2048之类。

分区建好后：

bash复制mkfs.xfs /dev/sdb1

如果你需要ext4，就用mkfs.ext4。选哪个文件系统？没有绝对答案，但这两类需要知道区别：

企业中如果数据盘主要是日志、备份、大文件，我倾向xfs；如果是数据库的数据文件、大量小文件，我反而会用ext4，或者直接交给数据库自己的存储管理。格式化之前一定要再确认一次盘符，因为mkfs会彻底清空分区里的数据，这个操作没有后悔药。

5.3 挂载与/etc/fstab：让磁盘开机后依然在线

格式化完之后，分区还不能直接用，需要挂载到某个目录。先创建挂载点：

bash复制mkdir -p /data
mount /dev/sdb1 /data

执行完df -h看得到/data就说明挂载成功。但仅仅这样，重启后挂载会消失，所以必须写进/etc/fstab。这是整个磁盘操作里最容易出错的地方。

一个典型的/etc/fstab行：

bash复制UUID=xxxxxx-xxxx-xxxx /data xfs defaults,nofail 0 0

字段顺序是：设备、挂载点、文件系统类型、挂载选项、dump标志、fsck检查顺序。我用UUID作为设备标识，加nofail选项的含义是：即使这块盘没找到，系统也能继续启动，不会卡在emergency mode等人工干预。对非系统盘来说，nofail几乎是标配，能最大程度避免机器因某块数据盘异常而无法开机。

写完后不要马上重启，先执行一遍：

bash复制mount -a

这个命令会重新加载/etc/fstab里所有未挂载的分区，如果有语法错误，立刻就会报错。确认无误后再考虑重启，能省掉很多麻烦。

5.4 卸载失败与fstab写错后的自救

运维中经常遇到umount /data提示target is busy。这说明还有进程在使用这个挂载点下的文件。排查手段如下：

bash复制lsof /data
fuser -v /data

lsof能列出正在占用/data下文件的进程PID，fuser -v也有类似作用。找到进程后，要么正常停止，要么用kill -9强制结束（不到万不得已不用）。如果确实无法停止进程，想强制卸载可以用umount -l，但这个操作是“懒卸载”，容易造成文件句柄悬空，我通常作为临时手段，之后会尽快重启相关服务。

更惊险的是fstab写错导致重启后卡进emergency mode。这时候系统会提示你输入root密码。进去第一件事是把根文件系统改成可写：

bash复制mount -o remount,rw /

然后编辑/etc/fstab，把错误行注释掉或改对，保存后重启。经历过一次这个场景，你就明白为什么我坚持写nofail，也坚持写完先mount -a验证。

6. 磁盘“满”了但不知道哪里满：一类高危故障的完整排查

6.1 df -h和df -i分别在看什么

遇到“磁盘满”的报错，第一反应通常是df -h，这会显示容量使用率。但还有个极其容易忽略的维度是inode满。inode相当于文件系统里的档案索引编号，每个文件或目录都要占一个inode。当小文件数量多到爆炸时，磁盘空间可能还剩不少，但inode已经被用完，系统同样会报No space left on device。

排查时两条命令一起看：

bash复制df -h
df -i

如果df -h显示usage还有剩余，但df -i里某个分区的IUse%已经是100%，说明是inode资源耗尽。处理思路就是删除大量无用的小文件，常见元凶是邮件队列、临时缓存文件和PHP会话文件。可以用以下命令找出目录下文件数量：

bash复制find /var/spool -type f | wc -l

定位到某目录后，再决定是定时清理还是调整应用配置。

6.2 空间删了却没释放：“deleted”文件的锁

这是最让人抓狂的一种情况：你用du -sh /data统计，发现占用量不高，但df -h显示磁盘还是100%。原因是某个进程打开了一个很大的文件，之后你删掉了文件路径，但进程仍然持有这个文件的句柄，操作系统因此不会真正释放磁盘空间。

排查办法：

bash复制lsof | grep deleted

输出里会有进程名、PID和/path/to/file (deleted)的信息。处理方式有两种：一是重启这个进程，让句柄自然关闭；二是如果进程不能重启，可以用> /proc/PID/fd/文件描述符号把文件清空。但清空操作有风险，一般我会先联系业务方确认再动。

这个坑告诉我们一个日常工作习惯：清日志最好不要用rm删除正在写的日志文件，而是用truncate -s 0清空。否则旧的日志句柄还会继续占用磁盘，等磁盘满时才发现删了也白删。

6.3 用du和find逐层定位大文件、大目录

定位大目录时，我喜欢用du加排序组合一把梭：

bash复制du -h --max-depth=1 -x /var 2>/dev/null | sort -hr | head -20

-x的意思是不要跨文件系统，避免不小心统计到挂载的其他磁盘，导致数据不准。sort -hr能按人类可读格式正确排序，而不是把10G排在2M前面这种低级错误。

找大文件可以用find：

bash复制find /data -xdev -type f -size +500M -exec ls -lh {} \;

这条命令会列出/data下所有超过500MB的文件。实战中我遇到过的大型文件来源主要有几类：Nginx和Tomcat未轮转的日志、数据库备份文件、Docker容器日志、临时打包的tar.gz。知道了来源，清理策略也就清楚了，该上logrotate上logrotate，该做备份生命周期管理就做备份生命周期管理。

7. 一次真实迁移复盘：新机器上权限错乱是怎么发生的

7.1 rsync -a带不走ACL：拷贝时的保留参数问题

前面说的这些经验，我在一次数据迁移中集中遭遇了一遍。当时要把旧服务器上整个/data业务目录同步到新服务器，我下意识用了最常用的命令：

bash复制rsync -av /data/ root@新服务器:/data/

同步完成后，登录新服务器一检查，发现大量文件带ACL权限的标签全没了。原因不难理解：rsync -a虽然包含了常用的递归、链接、权限、时间、属主、组等保留项，但它默认不会保留ACL和扩展属性。对于使用了setfacl的目录，必须显式加参数。

正确姿势应该是：

bash复制rsync -avHAXA --numeric-ids root@旧服务器:/data/ /data/

这里-A保留ACL，-X保留扩展属性，-H保留硬链接。--numeric-ids的含义是保持数字uid/gid不变，而不是尝试把两边的用户名对应起来。这个细节非常重要，直接引出了下一个问题。

7.2 uid不一致：迁移后文件属主变成数字的根因

迁移后我执行ls -l，屏幕上出现一串数字属主，比如1004。一看新服务器/etc/passwd，根本没有uid 1004对应的用户。为什么？因为旧服务器上某个应用账号的uid是1004，新服务器装系统时创建的账号uid顺序不同，同样叫appuser的用户，在新系统上可能变成了1005。

文件系统里真正记录的其实不是用户名，而是uid。系统显示用户名，只是在ls时去/etc/passwd里做了一层翻译。用户名相同但uid不同，在新机器上就会显示成“用户名查无此人”，只给你留下一串数字。

解决办法是迁移前先在两台机器上统一uid，用usermod -u把账号的uid改成和目标一致。如果已经迁移完了，还有一堆文件属主是旧uid，可以用find匹配uid再统一改：

bash复制find /data -uid 1004 -exec chown appuser:appgroup {} \;

这个教训让我后来养成了一个习惯：任何跨服务器同步前，先把所有机器的账号清单和uid列出来做对比，而不是想当然认为用户名一样就万事大吉。

7.3 改完fstab之后，我用一整套自查项兜底

迁移中我还在新服务器上改了/etc/fstab，想把数据盘按新目录挂载。当时犯了所有新手都会犯的错：写完后没有执行mount -a验证就直接重启了。结果系统进了emergency mode，我花了二十分钟才救回来。所以我现在每次改完fstab，都必须做四步自查：

第一，检查blkid里的UUID和fstab里的UUID是否一致。第二，执行mount -a，确认所有分区能成功挂载。第三，进入挂载点执行ls和touch一个临时文件，确认读写权限正常。第四，重启前再systemctl daemon-reload一次，避免有些手动挂载的服务单元状态混乱。

另外，迁移过程中如果用了tar打包，也要记得tar同样默认不保留ACL和xattr。打包时应该加--acls --xattrs，或者干脆用rsync做在线同步，少走打包解包的弯路。

7.4 迁移完成后我补充的权限检查习惯

迁移操作收尾前，我还会重点核对几件事：系统里是否存在文件属主不存在的“孤儿uid”；应用运行账号能否访问自己的日志目录和临时目录；有没有不小心把配置文件设成777；关键目录的setgid位置是否保留。我通常会生成一份清单：

bash复制find /data -nouser -o -nogroup 2>/dev/null

这条find命令可以快速找出属主或属组在系统里不存在的文件。只要是输出不为空，就说明账号体系没同步干净。把它和上一节的uid问题结合起来，基本能覆盖绝大多数权限迁移隐患。

直到所有权限清单和挂载项核对完，我才会关掉旧服务器。这个习惯后来帮我避免了好几次半夜被叫起来修数据的尴尬。权限管理和磁盘操作这两块，说到底都是在和“细节失控”作斗争，认真梳理一次迁移过程，比单纯背五十条命令管用得多。