Linux 目录结构与权限详解：从 rwx 到 Permission denied 的排查指南

刚接触 Linux 的人十有八九是被两座大山拦住的一个是目录结构一个是权限。这两样东西放在“Day 1”讲不是因为你一天就能背完而是因为你从第一次敲命令起就会不断地撞见它们——ls 要看目录写文件要权限启动服务也要权限报错一大堆核心问题往往就是“没权限”或者“找错目录”。这篇我把自己的实战经验和带新人时最容易讲明白的思路全拆出来不搞晦涩的背诵清单而是把“目录结构”和“权限”这两套东西讲成一个有机的整体。适合刚上手的运维新人、想搞懂 Linux 的开发同学也适合那些已经被 Permission denied 折磨过几轮、想彻底搞懂原理的人。1. 先看懂 Linux 目录结构从“一切皆文件”说起1.1 根目录与挂载点Linux 的“世界观”和 Windows 完全不同在 Windows 里你习惯的是 C 盘、D 盘、E 盘每个盘有独立根数据都存在“盘符”里。Linux 不是这个逻辑它的最终极目录只有一个——/也就是根目录。所有的文件、设备、分区全都挂在以/为起点的这一棵目录树下面这就是常说的“一切皆文件”。注意“挂在”这个词它不是文字游戏而是 Linux 真正的核心机制。假设你有一块新硬盘想在系统里用不了“点击挂载然后出现一个新盘符”而是要把这块硬盘格式化之后挂载到某个目录上。比如你执行mount /dev/sdb1 /data之后你往/data里写文件实际是写到了那块硬盘上。目录就是挂载点它像一扇门门后面的空间来自不同的设备。我第一次接触这概念时也懵后来给同事打了一个比方根目录/相当于整个房子的地基而/home、/var、/opt这些目录相当于一个个房间。有些房间是盖房子时自带的根分区的一部分有些房间是后来接出去的小仓库独立分区挂载进来的。你存取东西不需要关心它具体在哪个仓库只要走这个房间的门就行。这个认知非常重要因为它能解释后来很多“怪现象”为什么某目录空间不够、为什么 df 显示不同使用率、为什么删不掉文件——可能根本不是权限问题而是挂载的磁盘已经只读。理解挂载点还有一个实际好处排查问题时你会第一时间用df -h看各目录挂在哪块分区、还剩多少空间而不是傻乎乎地在全盘找文件。这也是 Day 1 就该养成的习惯。1.2 核心目录逐一拆解这些目录不是让你背的是让你知道去哪找东西很多人学目录结构会陷入“死背”模式/etc是什么、/var是什么背完了转头就忘。我觉得更好的方式是把目录理解成“功能分区”出了什么事该去哪个目录找答案。下面这张表是日常最高频会打交道的核心目录。目录作用拿到它你会想到什么/etc系统与应用的配置文件集中地改配置、调参数先进这翻/var可变的运行数据日志、缓存、队列排查问题优先看/var/log/usr系统自带的软件与库文件类似 Windows 的 Program Files装系统包的二进制大多在这/home普通用户的家目录个人文件、配置、脚本放这/rootroot 用户的家目录别看名字特殊本质也是家目录/tmp临时文件程序运行时的临时产物重启可能被清/opt第三方软件安装位置手动解压的那些商业软件常在这/proc虚拟文件系统内核运行时的信息内存、CPU、进程信息全在这不占磁盘/dev设备文件磁盘、终端等设备对应的文件/mnt/media临时挂载点和可移动设备挂载点手动挂载 U 盘、光驱常用/run运行时数据系统启动后生成很多服务进程的 pid 文件、socket 文件在这/sys内核与设备模型信息一般开发者很少直接碰这表里的每一个目录背后都有故事。比如/etc我最常做的事就是改完配置文件后立刻备份cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak。这不是小题大做是因为nginx语法检查过了、重启服务后直接起不来有备份能让你一分钟回滚。再比如/var里的/var/log/messages或/var/log/syslog几乎是我排查服务器问题的第一站。只要出现奇怪的问题第一反应永远是“去日志里翻”而日志的位置十有八九就在/var/log。/tmp也是一个容易被低估的目录。很多程序会把临时文件写在这里但它的大小通常有限制而且某些系统会定期清理。你要是把重要数据直接扔/tmp重启之后找不回来是非常正常的事。我在生产环境里见多了因为把任务脚本输出写到/tmp、结果被系统清掉导致任务失败的案例所以重要数据永远要放到持久化目录比如/home或/var/data。1.3 理解 FHS 标准为什么大家的 Linux 目录长得差不多你可能会发现无论装的是 Ubuntu、CentOS、Debian 还是国产的麒麟系统目录的基本框架都差不多这是因为各发行版都遵循一个叫做 FHSFilesystem Hierarchy Standard文件系统层级标准的规范。这个标准规定了目录结构和用途保证你换了发行版不至于完全迷路。但要注意这套标准是“活”的。近几年很多主流发行版做了一个大动作把/bin、/sbin合并到/usr/bin和/usr/sbin/bin和/sbin变成了指向/usr/bin和/usr/sbin的软链接。我第一次在一个新系统里跑ls -l /bin时看到bin - usr/bin还愣了一下后来才明白这是在统一文件系统布局让根分区更精简。你在 Ubuntu 22.04、CentOS 9 这些新版本里都会看到这种现象不要觉得奇怪。还有PATH这个概念跟目录结构强相关。每次你敲nginx、systemctl、python3这些命令时系统到底去哪找可执行文件就是靠环境变量PATH。你可以执行echo $PATH看看输出通常是一串用冒号分隔的目录路径。系统会按顺序在这些目录里搜索你输入的命令。所以很多新手说“我明明把脚本放到/opt/myapp/run.sh了为什么运行不了”原因一般有两个脚本没有执行权限或者脚本所在目录不在PATH里。前者是权限问题后者是目录问题两个概念就这样交叉在一起。2. 权限模型读、写、执行的三角关系2.1 三类主角属主、属组、其他用户Linux 的权限模型不复杂关键要抓住三个主角文件的主人owner、文件所属的组group、以及除了前两者之外的所有人others。你执行ls -l时会看到类似root root这样的两列信息第一个root是文件的属主第二个root是文件的属组。为什么要分“组”这一层我给你一个非常常见的真实场景你们团队有 5 个开发都在同一台测试服务器上项目目录在/opt/project。你希望 5 个人都有读写权限但希望其他人连看都别看到。如果只针对单个人设权限你得一个一个加非常麻烦。这时候你就建一个devteam组把这 5 个人都加进组里然后把目录属组改成devteam组权限设为读写。这就是组的价值它是权限管理的最小单元让批量控制变得高效。很多老手在排查权限问题时第一件事就是看两个id你自己是谁、文件属于谁。新手往往会卡在“为什么我删不掉这个文件”却忘了先确认自己是不是文件的属主。记住一条基本原则Linux 判断你有没有权限首先看你是三类角色中的哪一类然后用对应的那组权限来判断不搞“叠加”那套。你是属主就看属主权限位你是组成员就看组权限位你只是个路过的其他用户就只看其他用户权限位。这个逻辑不搞清楚后面什么 ugo、rwx 全都白搭。查看自己身份用whoami查看所属组用groups查看文件的属主属组就是用ls -l。这三个命令组合起来90% 的“谁有权限”问题都能当场看清。2.2 rwx 三元组读、写、执行分别在文件和目录上意味着什么权限的核心就三个字母r读、w写、x执行。但同样一个字母作用于普通文件和作用于目录时含义有微妙的差异这是笔者见过最多理解偏差的地方。先看文件。r表示能读文件内容比如cat一个文件w表示能修改文件内容比如用编辑器打开后保存x表示能把它当作程序来运行。这里有个陷阱如果你只有r没有w你是可以看内容的但改不了如果你只有w没有x你会写但它不能被当成程序执行。再看目录这个必须重点说。目录的r权限是“能不能列出这个目录里面有什么”也就是能不能ls这个目录目录的w权限是“能不能在这个目录里创建、删除、重命名文件”目录的x权限是“能不能进入这个目录”也就是能不能用cd进去。我经常打比方目录的读权限像你站在房间门口看门牌号列表目录的执行权限像得到了一把能打开房间门的钥匙。如果你只有读权限没有执行权限你ls能看到文件名但一旦想cd进入或者访问里面的文件系统会直接拒绝。这解释了无数新手遇到的“怪事”我能 ls 看到文件但 cat 它却提示 Permission denied原因就是你对它所在目录没有执行权限路径上的每一层都进不去当然碰不到文件。另外一个高频误区很多人以为要删除一个文件必须有“删除这个文件的权限”。实际上 Linux 里并没有“删除权限”这个东西删除操作的本质是修改父目录的目录项所以决定权在父目录的w权限上。打个比方文件像贴在公告栏上的一张纸你要把纸撕下来需要的是“可以修改这个公告栏”的权限而不是“这张纸同意被撕”的权限。这就是为什么有时候一个文件明明是 777你却没权限删它——因为管着它的那个父目录不让你写。反过来就算文件是只读的只要父目录能写你照样能把它删掉重来。2.3 数字权限三位八进制是怎么来的权限除了用rwx这种符号表示更常用的是数字形式比如经典的755、644、600。rwx和数字之间有一套非常简单的对应r记 4 分w记 2 分x记 1 分。每个角色把三个权限的分数加起来得到一个 0 到 7 之间的数字三个角色拼在一起就形成了三位数。我举个具体例子。假设你希望一个脚本文件属主可以读写执行rwx4217、组内成员可以读和执行r-x4015、其他用户只能读r--4004。那这个文件的权限就是754。用ls -l看到的对应关系是-rwxr-xr--第一位-表示普通文件后面三组字符分别对应属主、属组和其他用户。为什么要掌握这套换算因为实际工作时你看到数字的机会比看到符号多得多。配置文件里写umask 022别人给你的安装文档里写chmod 777 run.sh这些东西需要你一眼就知道意味着什么。777就是所有人都能读写执行600就是只有属主能读写其他人都没权限。掌握 4-2-1 这个编码规则比你背一堆常用值要可靠因为你能临时推算任何权限组合。这里顺便说一句安全观777是个使用频率极高但风险极高的权限。新手图省事一遇到权限不够就chmod 777这在个人虚拟机里没问题但在生产环境就是一个巨大的安全漏洞。任何用户都能改你的脚本和二进制意味着任何用户都能植入恶意代码再借脚本本来执行。我的习惯是能不给的权限绝对不给先给最小权限不够再加。比如配置文件通常640脚本通常750完全没有理由让全局可写。3. 实操从 ls -l 到权限管理的完整流程3.1 读懂 ls -l 的输出十个字符里的全部秘密在动手改权限之前先确保你能完整看懂ls -l的结果。我随手建一个测试文件执行ls -l得到$ ls -l test.sh -rwxr-xr-- 1 dev dev 1024 Jun 1 10:00 test.sh这串内容从左到右可以切成这么几块看最开头的-rwxr-xr--是文件类型加权限位一共 10 个字符第 1 个字符-表示普通文件如果是目录会显示d符号链接显示l设备文件显示b或c后面的 9 个字符按三组排列分别是属主权限rwx、属组权限r-x、其他用户权限r--。接着的数字1是硬链接数量再往后两个dev分别是属主和属组1024是文件大小单位是字节Jun 1 10:00是最后修改时间最后test.sh是文件名。这一行信息量很大但日常最需要盯着的永远就是权限段和属主属组段。这里还要知道一个细节有些文件权限位末尾会出现一个比如-rw-r--r--。这个加号表示该文件设置了 ACL访问控制列表这是一种比传统 ugo 权限更精细的权限控制方式。你可以用getfacl查看具体规则用setfacl -m u:user1:rw file给指定用户单独授权。ACL 在复杂协作场景非常有用但它也是很多人排查权限问题时容易忽略的暗坑明明 ugo 权限看着没问题可你就是没权限一查才发现是 ACL 在起作用。3.2 chmod、chown、umask权限调整三件套平时改权限用的最多的就是chmod。它有两种写法我建议都掌握。符号模式适合精细调整比如给当前用户加执行权限chmod ux script.sh去掉其他用户的写权限chmod o-w file.txt给属组同时加读和执行chmod grx dir。符号模式的好处是只动你要动的那一位其他不碰非常适合调错。数字模式适合整体设置比如chmod 644 notes.txt、chmod 750 /opt/project。我在批量操作时更倾向数字模式因为它一次就能把三个角色都定下来可读性也强。给个实际例子初始化一个新项目的标准操作是mkdir /opt/project chown dev:devteam /opt/project chmod 750 /opt/project这样项目目录的属主是dev属组是devteam属主完全控制、组内成员可读可执行、其他用户完全无权。对大多数项目来说这已经是一套很稳的初始权限。紧接着是chown它负责改属主和属组。注意chown通常需要 root 权限普通用户不能随便把文件“送”给别人否则整个权限体系就乱了。常用法则是chown user:group file只改属主用chown user file只改属组用chown :group file。还有一个特别实用的小参数-R递归修改目录下所有文件chown -R dev:devteam /opt/project。最后讲umask。它跟创建文件的默认权限直接相关。系统里你新建一个文件默认权限并不是666而是666减去umask的值。绝大部分系统默认umask是022所以新建文件的默认权限是666 - 022 644也就是-rw-r--r--新建目录的默认权限是777 - 022 755。这个“减去”的操作逻辑你要理解文件本底就不该带执行权限所以从 666 出发目录必须有执行权限才进得去所以从 777 出发。你在/etc/profile或者~/.bashrc里能看到 umask 的设置改了它就能控制以后创建文件的默认权限。安全要求高的服务器会把 umask 设成027这样其他用户直接什么都看不了。3.3 特殊权限setuid、setgid、粘滞位平时不常见但关键时刻救命除了普通的 rwxLinux 还有三个特殊权限它们一般出现在可执行程序和共享目录上。不常遇到但一遇到就会觉得“这什么鬼”所以专门说一下。第一个是 setuid数字形式是 4符号是s例如chmod 4755 file。它最经典的例子就是/usr/bin/passwd普通用户都能用它修改密码而修改密码这件事本质要写/etc/shadow这个文件只有 root 才能写。为什么普通用户能改因为 passwd 程序带有 setuid 位它被执行时进程的有效身份会临时变成文件属主root于是获得了修改 shadow 文件的资格。我提醒一句给自研程序随意加 setuid 是极其危险的相当于让任何执行者瞬间拥有 root 权限攻击面非常大。生产环境里看到不认识的 setuid 文件建议高度警惕。第二个是 setgid数字形式是 2符号也是s通常用在目录上。目录加了 setgid 位之后任何人在里面新建的文件其属组会自动继承这个目录的属组。这个特性在团队共享目录中非常有用大家往同一目录里放文件文件属组自动统一就不用每个文件都手动chown了。第三个是粘滞位sticky bit数字形式是 1符号是t最典型的是/tmp目录权限显示为drwxrwxrwt。粘滞位的作用是在一个任何人都能写的共享目录里只有文件属主、目录属主或 root 才能删除或重命名文件。这防止了“我能进这个目录就能删别人临时文件”的乱象。没有粘滞位/tmp早就被搞乱了。还有一招很多人不知道的“保护符”chattr i file。这个命令不是改 rwx 权限而是给文件加不可修改的 immutable 标志。加了之后哪怕是 root也无法修改、删除、重命名该文件直到你先执行chattr -i file取消这个标志。用lsattr file可以查看这个隐藏属性。我常在关键配置文件和证书上加上 i 保护防止手滑或脚本误删。效果立竿见影比单纯改权限强硬得多但自己也要记着否则后面真的要改的时候会发现“root 都删不掉”别慌去掉 i 标志就行。3.4 sudo不是切换用户而是用最小化权限办大事找准时机提 sudo这是每个新手都会经历的过程。输入sudo ls /root能看是因为当前用户被加入了 sudo 组能用 root 身份执行命令。sudo 和直接切换成 root 的本质区别在于sudo 是按命令级别授权执行完就回到普通身份而su或su -是直接换到 root 的完整会话。在生产服务器上我强烈建议不要没事就su -变 root而是习惯用 sudo。原因是每个普通人都有可能在服务器上留下不安全的操作切换 root 后如果忘了退出一个误操作可能删掉整个系统。sudo 也带审计日志执行过什么都记录在案出了问题至少能追溯。sudo 的配置在/etc/sudoers文件里常规习惯是不要直接改这个文件而是用visudo命令编辑因为它会在保存前帮你检查语法避免写错导致 sudo 全废。比如说给dev用户授权所有命令可以加一行dev ALL(ALL) ALL如果希望某个用户只能跑systemctl restart nginx就写成dev ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx。这就做到了权限最小化他只能干这一件事其他什么都干不了。别小看这个习惯很多安全事件就是 sudo 权限给得太宽。4. 权限问题排查实录Permission denied 之后我做的第一件事4.1 高频 Permission denied 原因排查顺序实战中权限问题报错花样很多但原因逃不出下面几类。我建议按这个顺序去排查能省大量时间。第一查身份。先执行id看当前用户再用ls -l看目标文件属主属组和权限。如果当前用户不是属主、也不在属组里那就是其他用户只能看 others 那组权限。这一步 80% 的问题当场就能判断出来。第二查路径。很多新手只盯着最终文件忽略了路径上每一层目录。比如想访问/data/app/log/error.log但/data的权限是750而你根本不在能进/data的组里那你无论对error.log拥有多么牛的权限照样进不去。排查时用namei -l /data/app/log/error.log这个命令它会一行行列出路径上每个部分的权限一目了然。第三查 ACL 和隐藏属性。执行getfacl file看有没有多余的 ACL 规则执行lsattr file看有没有 immutable 这类隐藏标志。往往 ugo 权限没问题却被这两样东西卡住。第四查挂载与文件系统状态。执行mount | grep 目录或df -h确认目录所在分区是不是以只读方式挂载的。如果输出里有ro那就是文件系统层面拒绝了所有写操作这已经不是权限能解决的问题了要重新挂载成读写mount -o remount,rw /但生产环境要先确认原因再动。下面是我做的一个速查表可以贴到笔记里报错现象大概率原因排查命令bash: xxx: Permission denied文件没有执行权限ls -lchmod xcat: xxx: Permission denied用户没有读权限或路径目录少 xls -lnamei -lrm: cannot remove xxx: Permission denied父目录没有写权限ls -ld 父目录bash: xxx: command not found目录不在 PATH 或脚本没执行权限echo $PATHOperation not permitted文件有 immutable 属性等隐藏约束lsattrchattr -iRead-only file system分区只读挂载mountdf -h4.2 无权限删除的深层原因为什么 root 也可能删不掉文件“删除不了”这个事我单独拿出来说因为它的坑最深。普通用户删不掉文件第一反应是文件本身权限不够实际上重点在前面说过的父目录写权限。如果你确实对父目录有写权限但还是删不掉那就该查隐藏标志了。我在实践中遇到过一个特别典型的场景某台服务器上有个备份目录有个文件怎么删都删不掉root 执行rm -f都提示 Operation not permitted。当时第一反应就是lsattr果然文件带了一个i标志是之前为了防误删设置的 immutable。执行chattr -i file之后再删就秒删。所以如果你在搜索“无权限删除”相关的问题一定记住这条路先普通权限再父目录再隐藏属性最后文件系统状态。还有一种情况是挂载参数导致无法删除。比如某个目录所在的磁盘被mount -o ro挂了那肯定是删不掉的需要先mount -o remount,rw重新挂。再有一种情况是配合nosuid、nodev这些挂载选项产生的限制不过这类通常更偏安全加固方向日常场景用得不多作为了解即可。4.3 文件权限被搞乱之后怎么修复权限这玩意最怕的就是“乱”。有时候调试脚本手贱批量 chmod把整个项目 777 了一遍有时候安装软件自动改了家目录权限导致 SSH 直接拒绝登录。遇到这类局面我有几套修复思路。最简单粗暴的是对照正常系统或已知正确配置用chown和chmod一批批改回来。比如家目录权限SSH 有硬性要求用户主目录不能对 others 开放写权限否则会报bad ownership or modes。修复命令就是chmod 700 /home/user或者至少chmod 750然后chown -R user:user /home/user。如果是系统包的文件权限被改乱了比如/usr/bin下某个工具权限变成 777最靠谱的办法是用包管理器恢复出厂权限。RPM 系的发行版可以用rpm --setperms 包名和rpm --setugids 包名恢复指定包的文件权限与属主属组Debian 系可以用dpkg --verify检查哪些文件权限异常。这个方法比手动一个文件一个文件改要高效得多也更不容易出错。如果你要长期做审计建议养成用find检查异常权限的习惯。比如找出所有属主是 root 但全局可写的文件find / -user root -perm -ow -type f 2/dev/null再比如找出所有带 setuid 位的文件find / -perm -4000 -type f 2/dev/null这两个命令在高危环境下几乎每个安全巡检脚本里都有值得记下来。4.4 面试与实战都爱考的权限题一套思路带你看穿考点聊了这么多最后顺手把 Linux 面试里最常见的一类权限题要点说一下因为它的出题规律非常固定。第一类给一个ls -l输出让你说出权限位含义和对应的数字权限。这就考 4-2-1 换算别慌拆成三组一加一换算就出来了。第二类给umask 022问新建文件默认权限是多少。记住“文件从 666 减、目录从 777 减”这个规则答案就是644/755。第三类问为什么/tmp权限是1777。这里考的是粘滞位的意义大家都能写但只有属主能删自己的文件。第四类问如何给用户单独开权限而不影响其他人。答案就是 ACL 的setfacl -m u:username:rwx /path同时记得有些时候还要配合加上目录的执行权限。这四类会做了权限这层基础基本就稳了。这些考点不是死题它就是日常排查的浓缩版你知道怎么看权限、怎么算权限、怎么调权限面试背不背都无所谓重要的是真的动手试过。我每次带新人都会故意建几个权限故意设坏的目录让他们自己用刚才这几招去“破案”这个训练比刷十套题都管用。最后分享一点我自己的体会权限和目录结构这个东西千万不要指望一天背完也不要因为第一天看不懂就沮丧。它是那种“用得越多、理解越深”的知识你今天读到的每一个规律都会在接下来无数次的 Permission denied 和文件找不到里反复得到验证。真正厉害的不是记得多而是养成了遇到问题先查身份、再查路径、再看 ACL、最后看挂载的习惯。这套排查顺序比任何命令本身都值钱。你只要把今天这篇里的命令挨个敲一遍再故意弄坏几个权限试着自己修比看十遍别人的总结都有用。毕竟 Linux 这玩意亲手踩过坑才算真正学会。