我给生产环境配目录配置时吃过不少亏尤其是遇到/var分区被日志塞满、开发同学图省事把数据直接丢根目录这种操作几乎年年都会来一次。说实话Linux目录配置这个题目看起来基础但真正到了排查现场、部署服务、面试问答的时候底层逻辑不清就会非常难受。这篇文章就从实际运维和部署的视角出发把 Linux 目录配置的底层逻辑、核心目录、分区挂载、权限设置讲清楚顺便附上我踩过的坑和排查套路。无论是正在学 Linux 基础、准备面试还是要认真规划生产环境服务器目录这篇文章应该对你有用建议耐心看完。1. 目录配置到底在配什么先弄清底层逻辑1.1 目录不是“文件夹”而是挂载点和命名空间很多刚从 Windows 转过来的人会用“文件夹”的思维理解 Linux 目录这是第一步就会踩的坑。Windows 的 C 盘、D 盘是独立的盘符而 Linux 只有一个从/开始的目录树其他磁盘、分区、甚至设备都要通过挂载mount的方式接入这颗树。我经常用一个类比Linux 目录树就像一栋楼里统一的门牌号每个房间分区通过“挂载”这个动作贴上对应的门牌。你进入/var看到的可能是独立的一块磁盘也可能只是根分区里的一个普通目录这完全取决于管理员怎么配置。执行mount命令时能看到/dev/sda1 挂载到 /、/dev/sdb1 挂载到 /data这种信息目录背后可能是一块物理硬盘、一个逻辑卷、一块网络存储甚至是一个内存文件系统 tmpfs。所以配置目录的第一步是先弄清楚当前机器上有哪些挂载点、每个挂载点对应什么设备、容量多大。常用命令就是lsblk、df -hT、findmnt。我用df -hT最多因为能同时看到文件系统类型、挂载点和已用百分比。类型不同目录的行为差异非常大比如根分区一般是 xfs 或 ext4而/proc、/sys是伪文件系统里面的“文件”根本不占磁盘空间。1.2 三个底层规则FHS、路径解析、读写权限Linux 目录为什么会分成/bin、/usr、/var、/etc这一套最权威的依据是 FHSFilesystem Hierarchy Standard文件系统层次结构标准但它不是强制规定更像是一个“社区共识”。Fedora、Ubuntu、Debian 这些发行版基本遵守它但细节有差异比如 Arch 直接把/bin软链到/usr/binRed Hat 系列的/sbin也是软链。理解 FHS 的关键不是死记硬背而是抓住三条底层规则第一条路径解析规则。你敲ls /var/log的时候内核按绝对路径从/逐级往下找命令里的..代表上级目录、.代表当前目录、~代表当前用户的家目录。这个解析顺序决定了你写脚本、配 systemd service 时必须搞清楚工作目录否则经常出现“脚本明明存在但找不到文件”的情况。第二条读写权限规则。目录本质上也是文件但它存的“内容”是文件名到 inode 的映射。目录的读权限对应“能列出文件名”写权限对应“能创建或删除文件”执行权限对应“能进入这个目录”。所以你会看到/tmp这类目录的权限是drwxrwxrwt最后的t是 sticky 位意思是即使目录对所有人可写用户也只能删除自己创建的文件避免有人乱删别人的临时文件。第三条挂载规则。不想让某些数据被系统重装/崩溃波及就单独给目录建挂载点想限制缓存类目录的写入可以把它挂成 tmpfs想提高性能可以加noatime选项。目录配置的很大一部分工作就是设计挂载点。1.3 为什么按“静态”和“动态”拆分目录FHS 的拆分逻辑说穿了就是“按数据的生命周期管理”。我个人的理解是它把文件系统分成了两类一类是静态的、随系统安装就固定的内容比如可执行程序、系统库、默认配置另一类是动态生成的、持续变化的内容比如日志、临时文件、用户数据。典型的对应就是/usr和/var。/usr放的是程序本身正常情况下安装好之后基本不需要变/var放的是运行过程中不断膨胀的东西比如/var/log、/var/lib、/var/spool。系统设计者希望你把/usr挂在只读分区或单独小分区而给/var留出充足空间就是这个原因。我自己在规划生产服务器时习惯把/var单独分成一个大分区这样即使日志爆炸也只会拖垮/var根分区还能被抢救。这种拆分还有一个隐藏的好处支持只读根文件系统。在嵌入式 Linux 或加固过的服务器上经常把/、/usr设为只读启动后只把/var、/tmp、/run挂成可写。如果程序不在规范的位置读写数据比如非要往/usr/local下写日志这套“只读根可写数据”架构就直接崩了。这也是为什么资深运维对“软件装哪个目录、日志放哪里”这么敏感。1.4 用一条命令快速了解当前系统的目录布局拿到一台陌生的 Linux 服务器我一般先用一组命令把家底盘清楚# 查看所有挂载点及磁盘状态 df -hT # 查看块设备对应关系 lsblk -f # 看当前目录所在设备的挂载信息 findmnt -T /var # 查看文件系统类型和挂载参数 cat /proc/mounts一个实际中会遇到的细节cat /proc/mounts里能看到/dev/sdb1 /data ext4 rw,relatime这种字段。如果某个挂载点后面带有ro说明这个目录是只读的程序写入时会报 “Read-only file system”。我曾经排查过一个 Java 应用启动失败就是/data被误挂成只读应用写日志直接报错。这种问题如果不看挂载参数光看代码和日志很容易绕圈子。注意改挂载参数、改 fstab 之前一定先备份/etc/fstab。这条命令记住cp /etc/fstab /etc/fstab.bak。我见过太多人改坏了 fstab 导致开机直接进不了系统。2. 核心目录逐一拆解与日常踩坑点2.1 可执行文件目录/bin、/sbin、/usr/bin、/usr/local/bin 怎么选很多新手分不清/bin、/sbin、/usr/bin、/usr/local/bin这四个放可执行文件的目录。其实在近几年的发行版里/bin和/usr/bin已经通过软链绑在一起了使用上区别不大。真正有区分意义的是/sbin和/usr/sbin——它们传统上是放系统管理命令的比如fdisk、mount、useradd需要管理员权限才能跑。至于普通用户安装工具我更推荐关注/usr/local和/opt。/usr/local是给系统管理员手动编译安装软件用的目录结构完整/usr/local/bin、/usr/local/lib、/usr/local/etc它刻意和发行版自带的/usr分离避免你手动装的软件覆盖系统包。/opt则适合放那种自带完整目录结构的商业软件或大型套件比如某些 IDE、Oracle 客户端每个软件占一个子目录。实际部署时我会按这个规则来选发行版包管理器安装的软件/usr/bin、/etc不要手动干预手动编译安装的通用工具/usr/local/bin源码编译时用./configure --prefix/usr/local自带完整目录结构的大型软件/opt/软件名单个用户自己的脚本/工具~/bin不存在就创建2.2 /etc 目录配置文件的“高敏感区”/etc是 Linux 的配置中心里面几乎全是文本文件改错一个就能让服务起不来。Nginx 的/etc/nginx/nginx.conf、MySQL 的/etc/my.cnf、系统级的/etc/fstab、/etc/hosts、/etc/resolv.conf全都在这里。操作/etc有几个我强烈建议遵守的纪律。第一改任何配置文件之前先备份并养成加时间戳的习惯比如cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.20250115。第二不要轻易对整个/etc执行chmod或chown。我见过有人图省事直接chmod -R 777 /etc结果 sshd 因为密钥权限过宽直接拒绝服务最后只能进单用户模式修复。第三写系统配置前先检查语法比如 Nginx 可以用nginx -tsshd 用sshd -tsystemd 的 service 文件用systemd-analyze verify。/etc里还有几个容易被忽略的子目录比如/etc/skel/它存放的是新建用户家目录的默认模板文件。我的习惯是把.bashrc、.bash_profile、.vimrc提前放到/etc/skel/里这样每次useradd新用户他们自动就有合用的环境初始化配置省得逐个设置。2.3 /var 目录日志、数据与空间管理的主战场/var可能是我花费精力最多的目录因为生产环境里 99% 的“磁盘满”事故都是它惹的祸。它的核心子目录有三个/var/log放系统日志和应用日志/var/lib放数据库、软件包管理器的数据比如 MySQL 的 datadir 常见是/var/lib/mysqlrpm 数据库在/var/lib/rpm/var/tmp放重启后依然保留的临时文件。日志管理是 /var 的核心难点。先看一个实际案例某天我接到告警某服务器df -h显示/已用 100%。登录后执行du -sh /var/log发现 size 高达 60G其中/var/log/journal/占了大头。这是 systemd-journald 的默认策略问题——它把日志持久化到了/var/log/journal且默认没有限制最大体积。解决方法是# 设置日志最大体积为 500M并生效 journalctl --vacuum-size500M sed -i s/#SystemMaxUse/SystemMaxUse500M/ /etc/systemd/journald.conf systemctl restart systemd-journald这只是一个例子。生产环境我一般建议部署 logrotate把 Nginx、Tomcat、自研应用日志按天压缩保留 7~30 天。配置放在/etc/logrotate.d/核心参数有daily/weekly、rotate 30、compress、dateext、copytruncate。特别提醒copytruncate这个选项它先把日志复制一份再清空原文件适合无法让进程重新打开日志文件的场景如果应用支持重新打开日志文件用create是更干净的方式。2.4 伪文件系统与临时目录/proc、/sys、/dev、/run、/tmp除了真实磁盘上的目录Linux 还有一批伪装成目录的系统接口我习惯叫它们“伪文件系统”。/proc暴露内核和进程信息/sys暴露设备和内核参数/dev是设备文件所在地/run存放系统启动后的运行时数据。这些目录里的文件通常不代表真实的磁盘文件占用的空间是内存或内核动态生成的。很多人会在这里踩坑想清理磁盘空间时发现/proc里都是数字目录下意识想去删。这是大忌。/proc/kcore是内核内存的映射看起来有几个 G但删掉也无济于事还会引发系统异常。正确的姿势是深入了解这些入口/proc/meminfo看内存、/proc/cpuinfo看 CPU、/proc/sys/kernel/可以临时调整内核参数。调整时注意sysctl -w是立即生效但重启失效写入/etc/sysctl.conf才是持久生效。/tmp反而是更贴近日常的一个临时目录。系统服务、编译过程、临时下载都会写它。需要注意不要把它当永久存储用因为 systemd-tmpfiles 会定期清理超过一定时间的文件。在 Ubuntu 上如果/tmp挂载为 tmpfs重启后里面的内容全部清空。很多新手把数据库备份临时丢/tmp重启就没了求救时我只能解释“tmpfs 就是这么设计的”。2.5 权限与安全边界为什么不能随便 chmod 777目录配置里最影响安全的是权限。Linux 的基本权限模型是三组属主u、属组g、其他人o每组的读r4、写w2、执行x1加起来是一个数字。举例drwxr-xr-x就是目录主可以读写执行同组和其他人只能读和执行数字表示是755。从安全角度来看我强烈不建议习惯性chmod 777。有人为了让进程能写目录直接把整个应用目录改成 777结果任何用户都能删改线上文件。我处理过几次“网站被挂马”就是因为/var/www/html权限放开成了 777攻击者往里塞了 WebShell。正确的做法是属主设为应用运行用户属组设为共享组权限750或770。“最小权限”原则在目录配置里同样成立。提示目录上的执行权限叫“可进入权限”只有目录没有 x 权限即使你知道路径也cd不进去。排查“明明有读权限却进不了目录”时先检查上级目录有没有 x 权限。3. 实操篇从分区规划到权限落地的完整流程3.1 安装系统前分区规划怎么做一个实际例子目录配置中最难回头的一步就是系统安装时的分区。系统装完再调整分区非常痛苦所以安装前做好规划至关重要。我结合自己常用的场景给出一个做分区规划的参考方法注意这只是“基于我的常见实践”生产环境要根据业务调整。以一台 8 核 16G 内存、2T 磁盘的通用 Web 应用服务器为例我的建议分区方案大致是这样的挂载点建议大小文件系统用途与理由/boot1Gext4/xfs内核与引导文件不需要大但必须独立避免/满后开不了机/100Gxfs根目录存放系统程序和/usr正常不会膨胀太快/var200Gxfs日志、数据库等动态数据必须给足空间/tmp20Gxfs独立分区限制临时文件占满根分区/home500Gxfs用户数据、上传文件按需调整/data剩余xfs业务数据、应用资源独立挂载方便迁移计算逻辑并不复杂/按系统软件预估 30-50G 起步再加冗余/var按日志增长速度估算如果是日志集中型应用直接给到总磁盘的 20%~30%/home按并发用户数和用户存储配额估算。这里我给的是通用场景实际上遇到过内存数据库用/var当数据目录几百 G 远远不够那时要根据真实 workload 加大。需要注意的是 LVM逻辑卷管理在这里的价值。如果发行版支持我建议分区时直接选 LVM。它的核心优势是以后空间不够可以动态扩充不用重新分区。比如/var所在的卷组有剩余空间时执行lvextend -l 100%FREE /dev/vg/var xfs_growfs /var就能在线扩容不需要停机。3.2 挂载与 fstab格式化、挂载、开机自动生效一条龙如果系统装完以后才发现某些目录需要额外挂载或者要加新磁盘就需要走一遍“格式化硬盘 → 挂载 → 配置 fstab”的流程。我还是以新增一块 1T 数据盘挂载到/data为例实际操作步骤是# 1. 查看新磁盘的设备名 lsblk -f # 2. 创建文件系统假设新盘是 /dev/sdb mkfs.xfs /dev/sdb # 3. 创建挂载点目录 mkdir -p /data # 4. 临时挂载 mount /dev/sdb /data # 5. 获取新盘的 UUID blkid /dev/sdb # 6. 写入 /etc/fstab 实现开机自动挂载 echo UUIDxxxx /data xfs defaults 0 2 /etc/fstabfstab 的六个字段可以拆开理解设备标识、挂载点、文件系统类型、挂载参数、dump 备份标志、fsck 检查顺序。我特别强调两条经验一是挂载参数用defaults,noatimenoatime可以禁止访问时间记录减少不必要的磁盘写入二是设备标识尽量用 UUID 而不是/dev/sdb因为设备名可能在重启后变化比如内核识别顺序不同用 UUID 更稳。如果 fstab 配错导致重启进不了系统不要慌。进入救援模式或单用户模式后先执行mount -o remount,rw /因为只读状态下无法改文件修改 fstab再umount /data测试。我曾经因为图省事在 fstab 里直接写/dev/sdb结果重启时盘符变了系统直接进入 emergency mode花了半小时才救回来。自此以后一律用UUID。bind 挂载是另一个实用功能。想把/var/log放到一块独立大分区logs上但又不希望程序改动路径可以用mount --bind /mnt/logs /var/log这种方式日志文件还是在/mnt/logs物理存储但应用无感知。要让重启生效同样要写入 fstab方法是在 fstab 中加一行/mnt/logs /var/log none bind 0 0。注意 bind 挂载同样要求先有挂载点目录。3.3 权限配置实操普通目录、共享目录、特殊权限位目录权限的落地通常围绕“谁可以读、谁可以写、谁能进入”展开。比如新建一个数据目录/data/project归属用户app归属组devops要求组内可写组外不可访问mkdir -p /data/project chown app:devops /data/project chmod 770 /data/project这里770就是属主和属组有完整权限其他人没有任何权限。如果希望新创建的子目录自动继承组关系可以加setgid位也就是在权限数字前面加 2chmod 2770或chmod gs /data/project。设置了 setgid 后目录里新建文件、子目录的属组会自动变成devops这个技巧在团队共享项目目录时特别好用。顺便说一句setuid位前面加 4在可执行文件上表示以文件属主身份运行比如/usr/bin/passwd就是典型普通用户靠它获得临时提升权限修改密码。但如果对普通程序滥用 setuid等于把管理员权限送给所有启动该程序的用户非常危险。/tmp的drwxrwxrwt里的t是 sticky 位机制前面提过。如果你自己搭共享目录比如/srv/share想让所有人都能上传但只能删自己的文件操作是chmod 1777 /srv/share如果需要更细粒度的控制比如用户 A 只能写某个子目录、不能读其他目录就用 ACL。第一步确保文件系统挂载参数里有acl现在主流发行版默认开启。然后setfacl -m u:zhangsan:rwx /data/project setfacl -m u:lisi:r-- /data/project getfacl /data/projectACL 的本质是给传统的三组权限增加了更灵活的权限项适合“少数人有特殊权限”的场景。注意使用setfacl -R递归时会影响大量文件尽量在初始配置时一次性设好不要在大量数据落盘后再批量改。3.4 软件装好后怎么配置目录PATH、环境变量与符号链接目录配置不只是系统层面的挂载和权限也包含应用层面的“路径规划”。最常见的场景是你手动把 JDK 解压到/opt/jdk-17把 Maven 解压到/opt/maven-3.9然后在/etc/profile.d/java.sh里写入export JAVA_HOME/opt/jdk-17 export PATH$JAVA_HOME/bin:$PATH export MAVEN_HOME/opt/maven-3.9这里有个细节我反复跟人强调环境变量的读取顺序。用户登录后会依次加载/etc/profile、/etc/profile.d/*.sh、~/.bash_profile、~/.bashrc。想对所有用户生效就写/etc/profile.d/下的独立脚本想只对某用户生效就写他~/.bashrc。写完之后当前终端执行source /etc/profile或者重新登录才能生效。如果觉得环境变量文件名太多记不住也可以创建符号链接。比如把/usr/local/bin/java软链到/opt/jdk-17/bin/javaln -s /opt/jdk-17/bin/java /usr/local/bin/java但软链用多了也有坑。我经历过最经典的坑是程序通过readlink -f /proc/self/exe获取自己的路径如果exe是符号链接取到的往往是真实目标的位置而不是软链位置还有升级时将软链指向新版本旧配置却还在写旧目录。个人经验软链适合“版本切换”环境变量 PATH 适合“多工具统一入口”两者结合使用更顺手。4. 面试与运维高频问题速查与心得4.1 Linux 目录面试题高频考点整理一下 Linux 面试中经常出现的目录相关问题基本围绕概念、权限、路径三段展开。第一类是概念辨析。比如“/bin和/usr/bin有什么区别”“/etc和/var分别放什么东西”。这类题考察的都是对 FHS 的理解答的时候切忌背目录列表而是讲清楚“静态资源放系统区、动态数据放变量区、配置统一集中在 /etc”以及为何这样设计。第二类是权限计算。例如“有一个目录权限是drwxr-xr-x普通用户能在这个目录下创建文件吗”。答案是不能因为其他人没有 w 权限。再比如“某文件权限-rwxr-sr-x数字是多少”答案是2755因为有 setgid 位。这类题重点是理解权限的叠加和特殊位。第三类是路径与文件系统。比如“.bashrc和.bash_profile的区别是什么”“/tmp和/var/tmp的区别是什么”。.bash_profile是登录 shell 读取的.bashrc是交互式非登录 shell 读取的所以很多发行版在.bash_profile里去 source.bashrc。/tmp可能被 tmpfs 清空/var/tmp相对持久。面试中能结合实际踩坑案例输出通常比单纯背答案更有说服力。4.2 磁盘空间“满”的排查流程从 df 到 inode“磁盘满”是我处理过最多的 Linux 目录问题一套标准化排查流程能显著节省时间。先看整体容量df -hT确定哪个挂载点满再深入目录从根开始逐层定位du -h --max-depth1 /var | sort -h能快速看到/var下哪个子目录最大。如果定位到某个日志目录顺手用ls -lhS按大小排序看具体日志文件。看着像“空间不足但实际文件不大”时很可能是 inode 满了。inode 是文件系统的元数据索引每个文件/目录占一个如果小文件特别多inode 会先耗尽。排查方法是df -i find / -type f 2/dev/null | wc -l如果 inode 使用率 100%需要找大量小文件典型的是邮件队列/var/spool/mail、session 临时文件/var/lib/php/sessions、Docker overlay 目录残留。我之前排查过一次/占满但du查不到大文件的场景最后用lsof L1 | grep deleted发现是有进程删除了日志文件但文件句柄未释放空间被“幽灵文件”占用。重启对应进程后空间才释放这也是一个容易入门的经典坑。4.3 目录权限错乱后的紧急恢复权限错乱在实际运维中很常见有些是误操作有些是攻击者篡改。恢复的关键是“先让人能进系统再逐步修复”。如果只是想紧急恢复某个目录的基本权限常见做法是参考同目录正常权限来对齐。比如/tmp被误改成 755 导致程序无法清理共享临时文件我一般是chmod 1777 /tmp chown root:root /tmp ls -ld /tmp如果/etc权限大面积错乱比如 sshd 无法读取密钥可以先尝试ls -ld /etc /etc/ssh /etc/ssh/ssh_host_*检查属主和权限必要时与正常机器对比。ssh 私钥权限必须为 600、公钥可以是 644这是硬性要求。如果系统里连chmod都没法执行就要进入单用户或救援模式先mount -o remount,rw /再把权限修正回来。权限恢复类问题更重要的其实是日常预防至少每周跑一次关键目录权限检查脚本重点盯/etc、/var/www、/data等敏感目录发现 777 或非 expected 属主就告警。这个习惯远比等出问题后再紧急修复省心。4.4 常用命令速查与目录配置经验总结最后整理一份我日常使用率最高的目录相关命令表方便收藏参考需求命令查看磁盘分区总量df -hT查看inode使用情况df -i分析目录占用大小du -sh /var、du -h --max-depth2查看挂载关系和文件系统类型lsblk -f、findmnt查看目录是否为软链ls -ld /usr/bin修改属主属组chown user:group 目录递归修改权限chmod -R 750 目录查看特殊权限位ls -ld /tmp /usr/bin/passwd查看命令实际路径which nginx、type -a nginx查看环境变量echo $PATH、env再有就是关于目录配置的经验心得。我的体会有三点第一目录配置永远比想象中重要因为它决定了数据放哪里、谁能动、坏了怎么救这些是后续所有运维操作的地基第二别把“能跑”当成“没问题”很多故障隐患恰恰藏在目录权限过宽、挂载点不明、日志无限制增长里第三每次新上线服务我都会花十几分钟把它的目录、权限、挂载关系画清楚录入文档这十几分钟往往能省下未来几个小时的排障时间。我个人在实际操作中的体会是目录配置不是一个“一次性动作”而是一套持续维护的习惯。每装一个软件、每加一块磁盘、每新建一个用户都应该顺手检查一遍对应目录的用途和权限是否合理。把这些习惯固化下来你会发现自己处理服务器故障的效率有了明显提升。