我第一次把一个Linux系统的/目录当成“乱糟糟的杂物间”是在刚接手服务器那阵子。想看Nginx日志不知道该去/var/log还是/var/log/nginx想找PHP配置先在/usr/local翻了半天最后靠find / -name php.ini才捞出来。后来我把bin、dev、etc、home、lib、opt、usr、var这层目录从根目录开始一个个过了一遍突然就开了窍这套目录排序不是谁随手定的而是有一套“分工协议”在里面。搞清楚它们各自装什么、为什么这么分、系统出问题时该往哪个目录去查你才会真正觉得Linux不绕。这篇文章我打算用实际运维和开发里的真实场景来讲这几个目录适合刚入门Linux的同学也适合准备Linux面试、排查线上故障的工程师希望你看完能放下“背目录”的焦虑直接上手判断问题。1. 先从整体看Linux根目录的“分工逻辑”1.1 FHS让所有发行版“长得差不多”的规矩很多人一开始会把Linux根目录当成某个发行版自定义的文件夹堆砌其实不是。绝大多数主流发行版都遵守一套叫FHSFilesystem Hierarchy Standard的目录结构标准它规定了根目录下这些一级目录叫什么、主要放什么内容。FHS本身不是Linux内核的一部分它是社区维护、各大发行版共同遵循的约定所以你在Ubuntu里看到的/etc、在CentOS里看到的/etc职责基本一样只是软件包的名字和版本不同罢了。这套标准最大的价值是降低了迁移成本。你在一台Debian机器上习惯了把网络配置写在/etc/network/interfaces换到RHEL系列会发现路径变成/etc/sysconfig/network-scripts/ifcfg-xxx虽然flavor不同但大方向没变配置都在/etc下日志都在/var/log下可执行文件都在bin相关目录下。这种“大框架稳定、小细节灵活”的设定就是FHS的底层逻辑。我记得自己第一次从Ubuntu切到CentOS时也是靠着“先查/etc”这个惯性少走了很多弯路。1.2 用“公司部门”的类比记目录目录记不住是因为少了画面感。我习惯把根目录想象成一栋办公楼/bin和/usr/bin是公共工具间里面放着大家都能用的锤子扳手比如ls、cp、grep这些命令。/etc是行政制度室系统里所有软件的配置规则、开关参数、用户名单都归档在这里。/home是员工工位每个普通用户一个独立隔间自己的桌面、文档、配置都锁在自己卡座里。/lib是零件仓库程序运行时需要的动态库、内核模块堆在这里。/opt是外来事业部第三方商业软件、自带依赖的“大块头”都安排在这一层尽量不破坏公司原有秩序。/usr是标准办公用品库系统自带的大部分程序、库、文档都来自这里。/var是运营台账室日志、缓存、邮件队列、数据库状态凡是每天在变的“流水账”都留在这。/dev是外设接待口磁盘、终端、USB设备在Linux里以文件形式出现在这里程序通过读写这些文件跟硬件打交道。用这种方式过一遍你会发现自己记的不是目录名而是“东西该往哪个部门放”的直觉。后面不管看到什么奇怪路径先问一句“它属于哪个部门”定位速度立刻快一倍。1.3 目录不一定是“本地磁盘”也可以是挂载点还有一个容易踩坑的点根目录下的这些一级目录未必全都真实地“住在”根分区里。Linux的目录只是一个路径入口背后可以是一个独立磁盘分区、一块网络存储甚至是一个虚拟文件系统。比如/dev通常由devtmpfs自动挂载/proc和/sys是内核暴露状态的虚拟目录/run里是系统运行时的临时数据/var如果单独分了一个区那/var实际落在另一块磁盘上。这个区别在排查“磁盘满了”时特别重要。有时候你df -h看根分区还剩很多空间/var却报错就是因为/var被单独挂载了。脑子里没有“挂载点”这个概念就很容易误判。我的习惯是一上来先执行df -hT和mount搞清楚每个目录对应哪个设备、文件系统类型、挂载参数再去做清理或扩容。这个习惯能帮你避开“明明删了文件空间却没释放”这类经典坑。2. 核心目录逐个拆解bin、dev、etc、home、lib、opt、usr、var2.1 /bin与/usr/bin命令为什么有两个“bin”/bin是binary的缩写放的是系统启动和用户登录早期阶段就要用到的基本命令比如cat、ls、cp、mount、bash。老式Unix设计里根分区是小磁盘只放“能撬动系统启动”的精简工具而/users后来的/usr是第二个分区放更多普通命令。后来磁盘越来越大/bin和/usr/bin被合并成一个很多现代发行版里/bin已经是/usr/bin的软链接。你在Ubuntu的终端里执行ls -ld /bin会看到/bin - usr/bin就是这个历史演化的结果。和/bin对应的还有/sbin和/usr/sbin放的是需要root权限才能执行的管理命令比如iptables、fdisk、systemctl。普通用户执行这些命令时如果提示command not found先看看是不是PATH里没包含/sbin。配置PATH时我习惯把/usr/local/bin放在前面这样自己编译安装或手动放置的脚本会优先执行避免和系统自带的同名工具撞车。这里有一个很典型的热搜报错/bin/bash^M: bad interpreter: no such file or directory。原因是脚本在Windows下编辑过行尾带了\rWindows换行符Linux的/bin/bash把“/bin/bash\r”当成了解释器路径自然找不到。用dos2unix脚本名或者执行sed -i s/\r$// 脚本名就能解决。2.2 /dev设备在Linux里也是“文件”“一切皆文件”在Linux里不是口号/dev目录就是最直观的体现。你的磁盘/dev/sda、分区/dev/sda1、终端/dev/tty、随机数设备/dev/urandom全都以文件形式呈现。用户态程序不直接跟硬件驱动打交道而是通过open、read、write这些标准系统调用来操作设备文件简化了编程模型。我平时最常用的是lsblk看磁盘拓扑再用/dev/disk/by-uuid这种稳定路径定位分区因为设备名可能因为插拔顺序改变UUID一般不会变。挂载新数据盘时很多人习惯直接mount /dev/vdb1 /data但如果你有多块云盘重启后设备名漂移会让人很抓狂。所以我都会在/etc/fstab里用UUID或by-uuid路径挂载并且加上nofail选项避免某块盘缺失导致启动卡在rescue状态。/dev/null和/dev/zero也是排障好帮手把不关心的输出丢到/dev/null用/dev/zero生成指定大小的临时文件做写入测试。理解/dev的关键是明白“设备文件只是门铃真正响铃的是内核里的驱动”。2.3 /etc全系统的“设置总抽屉”/etc大概是我在一台新机器上最常光顾的目录没有之一。它集中存放系统的静态配置/etc/hostname定义主机名/etc/hosts做主机名与IP的本地映射/etc/fstab控制开机挂载/etc/passwd和/etc/shadow存用户账号/etc/sudoers控制提权规则还有systemd、ssh、nginx、mysql等各色软件的配置也基本都住在这里。很多软件配置采用“主配置文件conf.d子目录”的形式比如nginx.conf引入/etc/nginx/conf.d/*.conf这样你可以把不同站点拆成独立文件管理比一股脑写在一个大文件里清爽得多。改/etc下的文件第一原则是“先备份再修改后验证”。尤其系统关键配置改错了启动起不来是小事把整个环境搞到不可修复才头疼。我习惯在改动前cp一份带日期后缀的备份比如cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-20250101然后通过nginx -t之类的命令做语法校验再重载服务。另外sudoers文件一定要用visudo命令编辑它自带语法检查能防止你把自己唯一的提权通道写死。这个目录里还藏着一个常见的vim菜鸟梗有人退出时在普通模式下输入wq结果shell报/bin/sh: wq: command not found。其实vim里保存退出要按冒号进入底行模式即:wq回车或者直接用ShiftZZ。2.4 /home与/root用户的专属房间和超级管理员办公室/home是普通用户的家目录大本营每个用户对应/home/用户名里面放桌面、文档以及各种带点的隐藏配置。之所以把这些用户数据独立出来是为了和系统文件隔离系统坏了重装时只要保留/home分区用户数据还在。用户登录后自己的工作目录就是家目录程序也习惯在这里读写缓存与个性化设置比如.bashrc、.profile、.ssh/authorized_keys。/root是root用户的家目录跟/home保持分离防止普通用户误入或窥探所有者的私人配置。权限角度讲家目录一般建议750或700~/.ssh要700authorized_keys要600太开放会让ssh拒绝加载密钥并可能引发X11环境报错。热词里有个/usr/bin/xauth: error in locking authority file /home/sunrise/.xauthority根源往往就是/home/sunrise这个目录的属主或权限不对导致xauth无法写锁文件。修法很简单chown sunrise:sunrise /home/sunrise再修复权限级别。备份用户数据时千万别只备份可见文件隐藏配置里常藏着密钥、shell别名和软件授权丢了影响后续使用。2.5 /lib与/usr系统运行的“零部件仓库”和“程序总部”/lib用来存放系统启动和基础命令依赖的共享库比如libc.so.6还可能有/lib/modules存内核模块、/lib/systemd/system存systemd单位文件。现在很多发行版把这些都整合到了/usr/lib/lib只是软链接。程序在运行时需要加载.so动态库如果找不到就会抛类似error while loading shared libraries: libxxx.so: cannot open shared object file这样的错。解决这种问题先ldd /path/to/program看看缺哪些库再用系统包管理器搜对应包名安装最后ldconfig刷新缓存。/usr是系统自带程序的主体下面有/usr/bin、/usr/lib、/usr/share等子目录。重点说说/usr/local这个目录是给系统管理员手动编译安装软件用的默认源码configure --prefix/usr/local装上后二进制落/usr/local/bin库落/usr/local/lib和发行版自带的/usr区分开互不干扰。你手动装的nginx、redis、python最好都按这个规范走以后卸载也方便直接rm对应目录或make uninstall即可。/opt则定位成“第三方大型软件自留地”很多商业软件、自带依赖的应用比如企业微信Linux版、豆包客户端、Todesk、JetBrains系IDE都默认装在/opt/软件名下面。这种布局的好处是尽量自包含不污染系统全局。但隔离不代表完全免疫缺系统库照样会挂比如/opt/todesk/bin/todesk启动时报libxcb-keysyms相关错误就是因为系统缺少这个X11辅助库。用ldd检查、通过apt/yum安装libxcb-keysyms1或libxcb-keysyms1-dev一般就能解决。总结一下自己编译的放/usr/local商业闭源的大块头放/opt系统自带的归/usr。2.6 /var日志、缓存和“随时变化的系统账本”/var是variable的简写专门放运行过程中不断变化的数据。最常打交道的是/var/log里面躺着syslog、auth.log、nginx/access.log、mysql/error.log这一类运行日志。系统出了问题第一反应应该是先翻/var/log而不是瞎猜。日志可能很多别用cat硬看用tail -f、grep、journalctl按时间过滤效率高得多。/var/lib是各种软件保存状态数据的地方包管理器的database、容器镜像、数据库文件都可能在这比如/var/lib/dpkg用于dpkg记录已安装包/var/lib/docker是Docker的默认数据目录。这里有两个高频问题一是apt/dpgk报waiting for cache lock说/var/lib/dpkg/lock-frontend被占用这是另一个apt进程还在跑要么等要么确认无进程后删掉锁文件二是Docker把数据全堆在/var/lib/docker根分区不够用想迁移到别的盘。后面我会单独写迁移方法。另外/var/run通常是/run的软链接里面放着mysqld、sshd等服务的PID文件和socket文件。如果启动mysql时提示/var/run/mysqld does not exist就先mkdir -p /var/run/mysqld再chown给mysql用户问题基本消失。/var/spool一般放打印、计划任务这类队列文件/var/cache放应用缓存清理时别手动rm目录结构尤其/var/lib下的data目录最好用软件自带的命令或停止服务后再操作。3. 靠着目录结构把常见故障“降维打击”3.1 磁盘满了df、du、inode三连根目录设计成这么多分区一个直接好处是出了问题能快速圈定范围。磁盘写满时我先df -h看各分区使用率再用du -h --max-depth1 /var 这种逐级统计的方式缩小目标。比如定位到/var/log占用异常再看里面哪个日志文件最大通常就是没配logrotate或者某个服务在疯狂刷日志。清理正在被进程写入的日志时不要直接rm会导致进程持有的文件句柄依然占据空间正确做法是truncate -s 0 /var/log/xxx.log把文件清空但保留文件描述符。日志轮转可以用系统自带的logrotatejournald日志占用过大时执行journalctl --vacuum-size500M既省心又安全。还有一种“df显示没满但文件写不进去”的怪状多半是inode耗尽。临时文件、小文件数量爆炸时会占满inodedf -i可以看到。遇到这种情况用find /tmp -type f | wc -l或find /var -xdev -type f | wc -l统计小文件数量然后清理过期的临时目录基本能救回来。把“df -h、df -i、du”这三个命令配合使用大多数磁盘问题都能在两分钟内定位。3.2 软件装不上、锁冲突/var/lib下的“锁”是怎么回事包管理器为了不让自己打自己会在/var/lib/dpkg或/var/lib/rpm下放锁文件。新开一个终端执行apt install时如果系统里已经有另一个apt或dpkg进程在跑就会提示waiting for cache lock。这个“锁”不是给用户看的摆设是为了防止多个进程同时往包数据库写数据导致损坏。解决思路分三步先看有没有前台apt进程直接等它跑完没有前台进程用ps aux | grep apt或lsof /var/lib/dpkg/lock-frontend找具体占用进程确认是残留僵尸锁再sudo rm -f /var/lib/dpkg/lock-frontend并执行dpkg --configure -a清理状态。很多新手一看锁就想删但如果不确认进程就删有可能打断正在进行的安装留下半成品数据库。同样的逻辑也适用于/var/lib/dpkg/updates、/var/cache/apt。网络源有问题时我之前踩过坑下载CentOS Base源时把wget指定成-o /etc/yum.repos.d/centos-base.repo结果yum识别不了。所以编辑repo文件后建议先用yum repolist校验一遍别把“下载到目录”和“保存到文件”搞混。3.3 二进制、动态库、权限三个高频报错的“修法”我整理过日常运维里三类最高频的目录相关报错基本都能从目录结构和权限角度下手。第一类脚本解释器报错。bad interpreter这类十有八九是Windows换行符混进Linux文件。用file它的脚本返回CRLF行尾就能确认。修复用dos2unix或sed -i s/\r$//改完就能执行。更根本的办法是写代码/脚本时统一用LF换行Git的core.autocrlf设置也要注意避免把仓库里的脚本自动转成CRLF。第二类Xauthority、ssh key这类家目录权限报错。错误信息里如果出现locking authority file通常是家目录或子目录属主不对。比如/home/sunrise属于rootsunrise用户登录后没法写.xauthority。先chown -R sunrise:sunrise /home/sunrise再检查家目录权限别高于755.ssh目录保持700这样能避免一大部分诡异问题。第三类dynamic linker问题。启动程序报error while loading shared libraries直接用ldd /完整路径确认缺失项然后apt-file、yum whatprovides或搜索引擎找包含这个.so的包。装完后如果库在非默认路径需要把路径写进/etc/ld.so.conf.d/下的conf文件再ldconfig。这里有个血泪教训别随意往LD_LIBRARY_PATH里塞各种路径全局影响太大一旦写错可能导致终端命令行都起不来。3.4 移动/var/lib/docker到其他盘到底行不行这个问题几乎每周都能在社区看到根分区不够用/var/lib/docker占了几个GB能不能把它移到/data/docker答案是可以但一定要按正确流程操作否则容器数据分分钟损坏。我把步骤规整成四条停止Docker服务确保没有容器在写数据。systemctl stop docker。这一步不能省直接mv运行中的目录很容易导致数据损坏或目录不一致。复制而不是移动。rsync -aSvx /var/lib/docker/ /data/docker/保留权限、软链接、硬链接。复制前先确认data空间足够df -h /data对比du -sh /var/lib/docker。修改Docker的数据根。推荐在/etc/docker/daemon.json里写{data-root: /data/docker}而不是用软链接。软链接虽然也可以但某些升级或安全上下文下会出现问题比如SELinux标签不对导致容器起不来。启动服务并验证。systemctl start docker然后docker info | grep Docker Root Dir确认路径生效。再看原有容器状态docker ps -a应该还能看到旧容器数据卷也能正常加载。如果不想改daemon.json也可以用软链接方案先备份原目录迁移后ln -s /data/docker /var/lib/docker。但注意软链接方案在容器运行时可能遇到挂载传播问题某些存储驱动兼容性不好所以我在生产环境都优先用data-root。只要迁移前停服务、迁移时保留权限迁移后基本都是安全的。另外迁移不算备份重要的数据卷还是要用volume或bind mount定期做远端备份。4. 常见问题与排查技巧实录速查表为了方便查阅我把上文提到的典型问题整理成一张速查表。你可以把它当作“遇到报错怎么下手”的索引不用死记命令先找到对应目录再按思路展开就行。现象可能原因涉及目录/文件推荐排查动作/bin/bash^M: bad interpreterWindows换行符残留在脚本脚本首行、/bin/bashdos2unix脚本名或sed -i s/\r$//脚本名/bin/sh: wq: command not found在vim普通模式输入了wq/bin/sh按Esc后输入冒号再回车退出或ShiftZZwaiting for cache lockapt/dpkg进程占用锁/var/lib/dpkg/lock-frontend等或查进程确认无进程再rm锁并dpkg --configure -a/usr/bin/xauth: error in locking authority file家目录权限或属主不对/home/用户名/.Xauthoritychown -R 用户名:用户名 /home/用户名调整家目录权限cannot connect to docker daemon at unix:///var/run/docker.sockDocker服务没启动或socket缺失/var/run/docker.socksystemctl start docker检查dockerd状态mysqld_safe directory /var/run/mysqld doesnt existsMySQL运行目录缺失/var/run/mysqldmkdir -p /var/run/mysqld chown mysql:mysql /var/run/mysqld/opt/todesk/bin/todesk: error while loading shared libraries: libxcb-keysyms...动态库缺失/opt/todesk、/usr/libldd /opt/todesk/bin/todesk安装libxcb-keysyms相关包根分区磁盘写满日志或容器数据膨胀/var/log、/var/lib/dockerdf -h先定位分区du再定位目录清理或迁移/var/lib/docker占用过大镜像/容器/卷堆积/var/lib/dockerdocker system prune必要时data-root迁移到其他盘这张表里的问题多数都遵循同一个排查流程先看错误信息里提到哪个路径这个路径属于哪个一级目录再判断是权限、锁、依赖还是空间问题。不要一上来就乱删文件尤其/var/lib下的内容可能藏着软件数据库删掉就不好恢复。我在实际处理中还有一个心得出现问题先看日志说起日志又绕回/var/log所以目录意识和日志意识本身就是一回事。比如Docker起不来先journalctl -u docker启动日志Nginx打不开先/var/log/nginx/error.log。日志目录其实是所有目录里最优先该看的。5. 写在最后我多年养成的目录管理习惯讲了这么多目录最后分享几个我长期养成的养机习惯。第一拿到新服务器先花五分钟把目录“底账”摸清楚df -hT看分区cat /etc/os-release看版本lsblk看磁盘du -sh /var/log /home /opt /usr/local /var/lib/docker看看重点目录的体量。这些信息能在以后排障时省下大量时间也能尽早发现哪块分区布局不合理。第二改/etc或/var/lib下的关键数据前一定备份且验证可回滚。很多系统崩了不是软件不好而是操作的人没给自己留后路。第三能用软链接和data-root做迁移就别硬拷文件权限、属主、SELinux上下文这些隐藏属性在迁移时最容易丢rsync -a是比cp更稳的选择。这套目录结构的学习方法也很简单不必刻意背而是遇到一个命令就cd进相关目录看一眼比如遇到nginx就看看/etc/nginx、/var/log/nginx、/usr/share/nginx分别装了什么东西。时间长了你会发现自己对一个系统的理解已经从“一堆命令”变成了“一张地图”。地图在手Linux就不再是一堆零散报错的随机组合而是有规律、可推理、能预测的完整系统。这也是我这几年跟服务器打交道最大的体会。
一文搞懂Linux根目录结构：FHS、核心目录与故障排查指南
我第一次把一个Linux系统的/目录当成“乱糟糟的杂物间”是在刚接手服务器那阵子。想看Nginx日志不知道该去/var/log还是/var/log/nginx想找PHP配置先在/usr/local翻了半天最后靠find / -name php.ini才捞出来。后来我把bin、dev、etc、home、lib、opt、usr、var这层目录从根目录开始一个个过了一遍突然就开了窍这套目录排序不是谁随手定的而是有一套“分工协议”在里面。搞清楚它们各自装什么、为什么这么分、系统出问题时该往哪个目录去查你才会真正觉得Linux不绕。这篇文章我打算用实际运维和开发里的真实场景来讲这几个目录适合刚入门Linux的同学也适合准备Linux面试、排查线上故障的工程师希望你看完能放下“背目录”的焦虑直接上手判断问题。1. 先从整体看Linux根目录的“分工逻辑”1.1 FHS让所有发行版“长得差不多”的规矩很多人一开始会把Linux根目录当成某个发行版自定义的文件夹堆砌其实不是。绝大多数主流发行版都遵守一套叫FHSFilesystem Hierarchy Standard的目录结构标准它规定了根目录下这些一级目录叫什么、主要放什么内容。FHS本身不是Linux内核的一部分它是社区维护、各大发行版共同遵循的约定所以你在Ubuntu里看到的/etc、在CentOS里看到的/etc职责基本一样只是软件包的名字和版本不同罢了。这套标准最大的价值是降低了迁移成本。你在一台Debian机器上习惯了把网络配置写在/etc/network/interfaces换到RHEL系列会发现路径变成/etc/sysconfig/network-scripts/ifcfg-xxx虽然flavor不同但大方向没变配置都在/etc下日志都在/var/log下可执行文件都在bin相关目录下。这种“大框架稳定、小细节灵活”的设定就是FHS的底层逻辑。我记得自己第一次从Ubuntu切到CentOS时也是靠着“先查/etc”这个惯性少走了很多弯路。1.2 用“公司部门”的类比记目录目录记不住是因为少了画面感。我习惯把根目录想象成一栋办公楼/bin和/usr/bin是公共工具间里面放着大家都能用的锤子扳手比如ls、cp、grep这些命令。/etc是行政制度室系统里所有软件的配置规则、开关参数、用户名单都归档在这里。/home是员工工位每个普通用户一个独立隔间自己的桌面、文档、配置都锁在自己卡座里。/lib是零件仓库程序运行时需要的动态库、内核模块堆在这里。/opt是外来事业部第三方商业软件、自带依赖的“大块头”都安排在这一层尽量不破坏公司原有秩序。/usr是标准办公用品库系统自带的大部分程序、库、文档都来自这里。/var是运营台账室日志、缓存、邮件队列、数据库状态凡是每天在变的“流水账”都留在这。/dev是外设接待口磁盘、终端、USB设备在Linux里以文件形式出现在这里程序通过读写这些文件跟硬件打交道。用这种方式过一遍你会发现自己记的不是目录名而是“东西该往哪个部门放”的直觉。后面不管看到什么奇怪路径先问一句“它属于哪个部门”定位速度立刻快一倍。1.3 目录不一定是“本地磁盘”也可以是挂载点还有一个容易踩坑的点根目录下的这些一级目录未必全都真实地“住在”根分区里。Linux的目录只是一个路径入口背后可以是一个独立磁盘分区、一块网络存储甚至是一个虚拟文件系统。比如/dev通常由devtmpfs自动挂载/proc和/sys是内核暴露状态的虚拟目录/run里是系统运行时的临时数据/var如果单独分了一个区那/var实际落在另一块磁盘上。这个区别在排查“磁盘满了”时特别重要。有时候你df -h看根分区还剩很多空间/var却报错就是因为/var被单独挂载了。脑子里没有“挂载点”这个概念就很容易误判。我的习惯是一上来先执行df -hT和mount搞清楚每个目录对应哪个设备、文件系统类型、挂载参数再去做清理或扩容。这个习惯能帮你避开“明明删了文件空间却没释放”这类经典坑。2. 核心目录逐个拆解bin、dev、etc、home、lib、opt、usr、var2.1 /bin与/usr/bin命令为什么有两个“bin”/bin是binary的缩写放的是系统启动和用户登录早期阶段就要用到的基本命令比如cat、ls、cp、mount、bash。老式Unix设计里根分区是小磁盘只放“能撬动系统启动”的精简工具而/users后来的/usr是第二个分区放更多普通命令。后来磁盘越来越大/bin和/usr/bin被合并成一个很多现代发行版里/bin已经是/usr/bin的软链接。你在Ubuntu的终端里执行ls -ld /bin会看到/bin - usr/bin就是这个历史演化的结果。和/bin对应的还有/sbin和/usr/sbin放的是需要root权限才能执行的管理命令比如iptables、fdisk、systemctl。普通用户执行这些命令时如果提示command not found先看看是不是PATH里没包含/sbin。配置PATH时我习惯把/usr/local/bin放在前面这样自己编译安装或手动放置的脚本会优先执行避免和系统自带的同名工具撞车。这里有一个很典型的热搜报错/bin/bash^M: bad interpreter: no such file or directory。原因是脚本在Windows下编辑过行尾带了\rWindows换行符Linux的/bin/bash把“/bin/bash\r”当成了解释器路径自然找不到。用dos2unix脚本名或者执行sed -i s/\r$// 脚本名就能解决。2.2 /dev设备在Linux里也是“文件”“一切皆文件”在Linux里不是口号/dev目录就是最直观的体现。你的磁盘/dev/sda、分区/dev/sda1、终端/dev/tty、随机数设备/dev/urandom全都以文件形式呈现。用户态程序不直接跟硬件驱动打交道而是通过open、read、write这些标准系统调用来操作设备文件简化了编程模型。我平时最常用的是lsblk看磁盘拓扑再用/dev/disk/by-uuid这种稳定路径定位分区因为设备名可能因为插拔顺序改变UUID一般不会变。挂载新数据盘时很多人习惯直接mount /dev/vdb1 /data但如果你有多块云盘重启后设备名漂移会让人很抓狂。所以我都会在/etc/fstab里用UUID或by-uuid路径挂载并且加上nofail选项避免某块盘缺失导致启动卡在rescue状态。/dev/null和/dev/zero也是排障好帮手把不关心的输出丢到/dev/null用/dev/zero生成指定大小的临时文件做写入测试。理解/dev的关键是明白“设备文件只是门铃真正响铃的是内核里的驱动”。2.3 /etc全系统的“设置总抽屉”/etc大概是我在一台新机器上最常光顾的目录没有之一。它集中存放系统的静态配置/etc/hostname定义主机名/etc/hosts做主机名与IP的本地映射/etc/fstab控制开机挂载/etc/passwd和/etc/shadow存用户账号/etc/sudoers控制提权规则还有systemd、ssh、nginx、mysql等各色软件的配置也基本都住在这里。很多软件配置采用“主配置文件conf.d子目录”的形式比如nginx.conf引入/etc/nginx/conf.d/*.conf这样你可以把不同站点拆成独立文件管理比一股脑写在一个大文件里清爽得多。改/etc下的文件第一原则是“先备份再修改后验证”。尤其系统关键配置改错了启动起不来是小事把整个环境搞到不可修复才头疼。我习惯在改动前cp一份带日期后缀的备份比如cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-20250101然后通过nginx -t之类的命令做语法校验再重载服务。另外sudoers文件一定要用visudo命令编辑它自带语法检查能防止你把自己唯一的提权通道写死。这个目录里还藏着一个常见的vim菜鸟梗有人退出时在普通模式下输入wq结果shell报/bin/sh: wq: command not found。其实vim里保存退出要按冒号进入底行模式即:wq回车或者直接用ShiftZZ。2.4 /home与/root用户的专属房间和超级管理员办公室/home是普通用户的家目录大本营每个用户对应/home/用户名里面放桌面、文档以及各种带点的隐藏配置。之所以把这些用户数据独立出来是为了和系统文件隔离系统坏了重装时只要保留/home分区用户数据还在。用户登录后自己的工作目录就是家目录程序也习惯在这里读写缓存与个性化设置比如.bashrc、.profile、.ssh/authorized_keys。/root是root用户的家目录跟/home保持分离防止普通用户误入或窥探所有者的私人配置。权限角度讲家目录一般建议750或700~/.ssh要700authorized_keys要600太开放会让ssh拒绝加载密钥并可能引发X11环境报错。热词里有个/usr/bin/xauth: error in locking authority file /home/sunrise/.xauthority根源往往就是/home/sunrise这个目录的属主或权限不对导致xauth无法写锁文件。修法很简单chown sunrise:sunrise /home/sunrise再修复权限级别。备份用户数据时千万别只备份可见文件隐藏配置里常藏着密钥、shell别名和软件授权丢了影响后续使用。2.5 /lib与/usr系统运行的“零部件仓库”和“程序总部”/lib用来存放系统启动和基础命令依赖的共享库比如libc.so.6还可能有/lib/modules存内核模块、/lib/systemd/system存systemd单位文件。现在很多发行版把这些都整合到了/usr/lib/lib只是软链接。程序在运行时需要加载.so动态库如果找不到就会抛类似error while loading shared libraries: libxxx.so: cannot open shared object file这样的错。解决这种问题先ldd /path/to/program看看缺哪些库再用系统包管理器搜对应包名安装最后ldconfig刷新缓存。/usr是系统自带程序的主体下面有/usr/bin、/usr/lib、/usr/share等子目录。重点说说/usr/local这个目录是给系统管理员手动编译安装软件用的默认源码configure --prefix/usr/local装上后二进制落/usr/local/bin库落/usr/local/lib和发行版自带的/usr区分开互不干扰。你手动装的nginx、redis、python最好都按这个规范走以后卸载也方便直接rm对应目录或make uninstall即可。/opt则定位成“第三方大型软件自留地”很多商业软件、自带依赖的应用比如企业微信Linux版、豆包客户端、Todesk、JetBrains系IDE都默认装在/opt/软件名下面。这种布局的好处是尽量自包含不污染系统全局。但隔离不代表完全免疫缺系统库照样会挂比如/opt/todesk/bin/todesk启动时报libxcb-keysyms相关错误就是因为系统缺少这个X11辅助库。用ldd检查、通过apt/yum安装libxcb-keysyms1或libxcb-keysyms1-dev一般就能解决。总结一下自己编译的放/usr/local商业闭源的大块头放/opt系统自带的归/usr。2.6 /var日志、缓存和“随时变化的系统账本”/var是variable的简写专门放运行过程中不断变化的数据。最常打交道的是/var/log里面躺着syslog、auth.log、nginx/access.log、mysql/error.log这一类运行日志。系统出了问题第一反应应该是先翻/var/log而不是瞎猜。日志可能很多别用cat硬看用tail -f、grep、journalctl按时间过滤效率高得多。/var/lib是各种软件保存状态数据的地方包管理器的database、容器镜像、数据库文件都可能在这比如/var/lib/dpkg用于dpkg记录已安装包/var/lib/docker是Docker的默认数据目录。这里有两个高频问题一是apt/dpgk报waiting for cache lock说/var/lib/dpkg/lock-frontend被占用这是另一个apt进程还在跑要么等要么确认无进程后删掉锁文件二是Docker把数据全堆在/var/lib/docker根分区不够用想迁移到别的盘。后面我会单独写迁移方法。另外/var/run通常是/run的软链接里面放着mysqld、sshd等服务的PID文件和socket文件。如果启动mysql时提示/var/run/mysqld does not exist就先mkdir -p /var/run/mysqld再chown给mysql用户问题基本消失。/var/spool一般放打印、计划任务这类队列文件/var/cache放应用缓存清理时别手动rm目录结构尤其/var/lib下的data目录最好用软件自带的命令或停止服务后再操作。3. 靠着目录结构把常见故障“降维打击”3.1 磁盘满了df、du、inode三连根目录设计成这么多分区一个直接好处是出了问题能快速圈定范围。磁盘写满时我先df -h看各分区使用率再用du -h --max-depth1 /var 这种逐级统计的方式缩小目标。比如定位到/var/log占用异常再看里面哪个日志文件最大通常就是没配logrotate或者某个服务在疯狂刷日志。清理正在被进程写入的日志时不要直接rm会导致进程持有的文件句柄依然占据空间正确做法是truncate -s 0 /var/log/xxx.log把文件清空但保留文件描述符。日志轮转可以用系统自带的logrotatejournald日志占用过大时执行journalctl --vacuum-size500M既省心又安全。还有一种“df显示没满但文件写不进去”的怪状多半是inode耗尽。临时文件、小文件数量爆炸时会占满inodedf -i可以看到。遇到这种情况用find /tmp -type f | wc -l或find /var -xdev -type f | wc -l统计小文件数量然后清理过期的临时目录基本能救回来。把“df -h、df -i、du”这三个命令配合使用大多数磁盘问题都能在两分钟内定位。3.2 软件装不上、锁冲突/var/lib下的“锁”是怎么回事包管理器为了不让自己打自己会在/var/lib/dpkg或/var/lib/rpm下放锁文件。新开一个终端执行apt install时如果系统里已经有另一个apt或dpkg进程在跑就会提示waiting for cache lock。这个“锁”不是给用户看的摆设是为了防止多个进程同时往包数据库写数据导致损坏。解决思路分三步先看有没有前台apt进程直接等它跑完没有前台进程用ps aux | grep apt或lsof /var/lib/dpkg/lock-frontend找具体占用进程确认是残留僵尸锁再sudo rm -f /var/lib/dpkg/lock-frontend并执行dpkg --configure -a清理状态。很多新手一看锁就想删但如果不确认进程就删有可能打断正在进行的安装留下半成品数据库。同样的逻辑也适用于/var/lib/dpkg/updates、/var/cache/apt。网络源有问题时我之前踩过坑下载CentOS Base源时把wget指定成-o /etc/yum.repos.d/centos-base.repo结果yum识别不了。所以编辑repo文件后建议先用yum repolist校验一遍别把“下载到目录”和“保存到文件”搞混。3.3 二进制、动态库、权限三个高频报错的“修法”我整理过日常运维里三类最高频的目录相关报错基本都能从目录结构和权限角度下手。第一类脚本解释器报错。bad interpreter这类十有八九是Windows换行符混进Linux文件。用file它的脚本返回CRLF行尾就能确认。修复用dos2unix或sed -i s/\r$//改完就能执行。更根本的办法是写代码/脚本时统一用LF换行Git的core.autocrlf设置也要注意避免把仓库里的脚本自动转成CRLF。第二类Xauthority、ssh key这类家目录权限报错。错误信息里如果出现locking authority file通常是家目录或子目录属主不对。比如/home/sunrise属于rootsunrise用户登录后没法写.xauthority。先chown -R sunrise:sunrise /home/sunrise再检查家目录权限别高于755.ssh目录保持700这样能避免一大部分诡异问题。第三类dynamic linker问题。启动程序报error while loading shared libraries直接用ldd /完整路径确认缺失项然后apt-file、yum whatprovides或搜索引擎找包含这个.so的包。装完后如果库在非默认路径需要把路径写进/etc/ld.so.conf.d/下的conf文件再ldconfig。这里有个血泪教训别随意往LD_LIBRARY_PATH里塞各种路径全局影响太大一旦写错可能导致终端命令行都起不来。3.4 移动/var/lib/docker到其他盘到底行不行这个问题几乎每周都能在社区看到根分区不够用/var/lib/docker占了几个GB能不能把它移到/data/docker答案是可以但一定要按正确流程操作否则容器数据分分钟损坏。我把步骤规整成四条停止Docker服务确保没有容器在写数据。systemctl stop docker。这一步不能省直接mv运行中的目录很容易导致数据损坏或目录不一致。复制而不是移动。rsync -aSvx /var/lib/docker/ /data/docker/保留权限、软链接、硬链接。复制前先确认data空间足够df -h /data对比du -sh /var/lib/docker。修改Docker的数据根。推荐在/etc/docker/daemon.json里写{data-root: /data/docker}而不是用软链接。软链接虽然也可以但某些升级或安全上下文下会出现问题比如SELinux标签不对导致容器起不来。启动服务并验证。systemctl start docker然后docker info | grep Docker Root Dir确认路径生效。再看原有容器状态docker ps -a应该还能看到旧容器数据卷也能正常加载。如果不想改daemon.json也可以用软链接方案先备份原目录迁移后ln -s /data/docker /var/lib/docker。但注意软链接方案在容器运行时可能遇到挂载传播问题某些存储驱动兼容性不好所以我在生产环境都优先用data-root。只要迁移前停服务、迁移时保留权限迁移后基本都是安全的。另外迁移不算备份重要的数据卷还是要用volume或bind mount定期做远端备份。4. 常见问题与排查技巧实录速查表为了方便查阅我把上文提到的典型问题整理成一张速查表。你可以把它当作“遇到报错怎么下手”的索引不用死记命令先找到对应目录再按思路展开就行。现象可能原因涉及目录/文件推荐排查动作/bin/bash^M: bad interpreterWindows换行符残留在脚本脚本首行、/bin/bashdos2unix脚本名或sed -i s/\r$//脚本名/bin/sh: wq: command not found在vim普通模式输入了wq/bin/sh按Esc后输入冒号再回车退出或ShiftZZwaiting for cache lockapt/dpkg进程占用锁/var/lib/dpkg/lock-frontend等或查进程确认无进程再rm锁并dpkg --configure -a/usr/bin/xauth: error in locking authority file家目录权限或属主不对/home/用户名/.Xauthoritychown -R 用户名:用户名 /home/用户名调整家目录权限cannot connect to docker daemon at unix:///var/run/docker.sockDocker服务没启动或socket缺失/var/run/docker.socksystemctl start docker检查dockerd状态mysqld_safe directory /var/run/mysqld doesnt existsMySQL运行目录缺失/var/run/mysqldmkdir -p /var/run/mysqld chown mysql:mysql /var/run/mysqld/opt/todesk/bin/todesk: error while loading shared libraries: libxcb-keysyms...动态库缺失/opt/todesk、/usr/libldd /opt/todesk/bin/todesk安装libxcb-keysyms相关包根分区磁盘写满日志或容器数据膨胀/var/log、/var/lib/dockerdf -h先定位分区du再定位目录清理或迁移/var/lib/docker占用过大镜像/容器/卷堆积/var/lib/dockerdocker system prune必要时data-root迁移到其他盘这张表里的问题多数都遵循同一个排查流程先看错误信息里提到哪个路径这个路径属于哪个一级目录再判断是权限、锁、依赖还是空间问题。不要一上来就乱删文件尤其/var/lib下的内容可能藏着软件数据库删掉就不好恢复。我在实际处理中还有一个心得出现问题先看日志说起日志又绕回/var/log所以目录意识和日志意识本身就是一回事。比如Docker起不来先journalctl -u docker启动日志Nginx打不开先/var/log/nginx/error.log。日志目录其实是所有目录里最优先该看的。5. 写在最后我多年养成的目录管理习惯讲了这么多目录最后分享几个我长期养成的养机习惯。第一拿到新服务器先花五分钟把目录“底账”摸清楚df -hT看分区cat /etc/os-release看版本lsblk看磁盘du -sh /var/log /home /opt /usr/local /var/lib/docker看看重点目录的体量。这些信息能在以后排障时省下大量时间也能尽早发现哪块分区布局不合理。第二改/etc或/var/lib下的关键数据前一定备份且验证可回滚。很多系统崩了不是软件不好而是操作的人没给自己留后路。第三能用软链接和data-root做迁移就别硬拷文件权限、属主、SELinux上下文这些隐藏属性在迁移时最容易丢rsync -a是比cp更稳的选择。这套目录结构的学习方法也很简单不必刻意背而是遇到一个命令就cd进相关目录看一眼比如遇到nginx就看看/etc/nginx、/var/log/nginx、/usr/share/nginx分别装了什么东西。时间长了你会发现自己对一个系统的理解已经从“一堆命令”变成了“一张地图”。地图在手Linux就不再是一堆零散报错的随机组合而是有规律、可推理、能预测的完整系统。这也是我这几年跟服务器打交道最大的体会。
