如果你是第一次登录一台 Linux 服务器大概率会对着根目录发呆——bin、etc、usr、var、home、opt、dev、lib……这些名字看起来都对应着某个英文单词可真到用的时候才发现很多东西跟字面意思压根对不上。我刚入行那年就干过一件蠢事嫌 /var/log 下的日志太占空间直接把它整个目录删了结果服务确实不再报“磁盘满”但后面排查故障、做审计时什么都没得翻只能面对一堆残缺的历史记录干瞪眼。从那次之后我才真正明白Linux 的目录树不是文件夹的随机排列它背后有一套清晰的分级逻辑。把这套逻辑搞明白日常运维、搭环境、排查问题都能省下大量的时间。这篇文章就围绕 bin、dev、etc、home、lib、opt、usr、var 这八个最常被问到的目录展开把它们的用途、相互之间的关系、跟磁盘分区挂载的联系以及我实际踩过的坑都梳理一遍。不管你是刚接触 Linux 的新手还是用了一段时间但总觉得“知其然不知其所以然”的开发者这篇文章都值得花二十分钟读完。1. 目录树不是随便画的Linux 文件系统的分级规矩从哪来1.1 Windows 有 C 盘 D 盘Linux 为什么只有一根斜杠用惯了 Windows 的人脑子里对文件位置的直觉是“盘符 路径”C 盘装系统D 盘装软件E 盘存资料。Linux 完全不是这个玩法。整个文件系统只有一个根写作/。你插上一块新硬盘、一个 U 盘或者一张 SD 卡系统不会给它们分配“E 盘”“F 盘”而是让它们“挂”到某个目录下面你通过访问这个目录来读写设备里的文件。这就是 Linux 世界里最重要的概念之一挂载点。目录不只是一个存放文件的“文件夹”它更像一个“入口”。你可以把一块物理磁盘挂载到/home把另一块挂载到/var而用户访问/home/user/file.txt时根本不关心这个文件是在系统盘还是数据盘上。这种设计把“物理存储布局”和“逻辑访问路径”彻底解耦了这也是 Linux 能做超大集群、能灵活扩容的基础。如果你在终端里执行df -h会看到类似这样的输出Filesystem Size Used Avail Use% Mounted on /dev/sda1 98G 45G 53G 46% / /dev/sda5 196G 100G 96G 51% /home tmpfs 7.8G 0 7.8G 0% /run注意看Mounted on这一列。/dev/sda1这块分区挂载到了根目录//dev/sda5挂载到了/home。所以当你往/home/xxx里写文件时数据实际落到了 sda5 这块分区上往/usr、/etc里写文件时数据落到 sda1 上。学会用df -h查看挂载关系是理解目录树的第一步。1.2 挂载点目录就是通向磁盘的入口挂载这个动作命令行里用mount实现。比如我把一块移动硬盘设备识别成了/dev/sdb1想把它挂到/data目录下sudo mkdir -p /data sudo mount /dev/sdb1 /data执行之后/data目录就成了这块硬盘的入口你在/data里读写文件实际上就是在读写这块硬盘。反过来如果不挂载就算系统识别到了/dev/sdb1你也没法直接往里面存东西——在 Linux 里“识别到设备”和“可以访问设备上的文件系统”是两回事。这种“一切皆文件、目录即挂载点”的思想对理解后面的目录分工至关重要。比如/是整个系统的根但/home、/var、/boot这些目录完全可以是从不同分区甚至不同物理盘挂载进来的。这也就解释了为什么 Linux 的目录表里没有“我的电脑”那种多盘符视图因为一层层挂载点本身就是一个天然的、稳定的逻辑视图。1.3 FHS大家都在遵守的“目录公约”这么多目录每个该放什么不是某个发行版拍脑袋定的而是有一个文档标准在约束叫做 FHSFilesystem Hierarchy Standard文件系统层次结构标准。它规定了 Linux/Unix 系统根目录下每个一级目录的用途和内容范围。虽然 FHS 不是强制法律但几乎所有主流发行版都遵循它。FHS 的核心逻辑可以概括成三个维度可共享 / 不可共享有些数据可以在网络间共享给多台机器比如/home、/usr有些只能属于本机比如/etc、/boot。可变 / 静态静态数据是指系统运行期间基本不变的内容比如可执行文件、文档可变数据是指会不断增长或更新的内容比如日志、缓存、锁文件。用户 / 系统哪些是普通用户直接操作的数据比如/home哪些是系统自己运行需要的东西比如/bin、/lib。这几个维度交叉下来就形成了我们今天看到的这套目录结构。理解了这套“公约”你就不会再把日志、配置、程序、用户数据乱塞一气——因为每个目录该放什么背后都有明确的设计意图。2. bin、lib、usr程序文件的三层布局与演化逻辑2.1 /bin 与 /sbin系统启动时最早需要的可执行文件/bin是 binary 的缩写里面存的是可执行文件也就是“命令”。/bin/ls、/bin/cp、/bin/mv、/bin/bash这些基础命令都在这里。为什么要把一部分命令单独放出来而不是全部丢进/usr/bin这背后有一段历史包袱。在早期的 Unix 系统里/usr很可能是一个单独挂载的分区系统启动时不一定能保证它被成功挂载。而系统在启动早期、挂载/usr之前就需要一些基础命令来完成初始化工作所以必须把“启动必需”的命令放在根分区上。于是/bin里放的是“系统启动和修复必需的最小命令集”/usr/bin里放的是“系统完整启动后绝大多数普通命令”。/sbin里的 s 是 system 的意思它是“系统管理命令”比如fdisk、mkfs、iptables这些。普通用户通常不需要、也未必有权限执行它们一般只有 root 或 sudo 用户会用。部分/sbin命令在普通用户执行时甚至需要显式写全路径/sbin/iptables因为普通用户的 PATH 环境变量里可能根本不含/sbin。在比较新的发行版尤其是基于 systemd 的里/bin和/usr/bin很多时候是指向同一位置的软链接/sbin和/usr/sbin也一样。但对服务器运维来说心里还是要记住它们的原始分工根分区上的命令是为了“应急”/usr下的命令才是“日常”。2.2 /usr 不再是你家的“用户目录”很多新手看到/usr会以为它是用户的目录实际上它现在的身份是“系统级软件和共享资源的大本营”。/usr下有几个子目录特别重要/usr/bin绝大多数可执行程序安装位置你apt install或yum install的软件主程序大多会放进这里。/usr/sbin系统管理类的程序。/usr/lib与/usr/bin配套的库文件。/usr/share程序运行需要的数据、文档、图标、man 手册等平台无关的共享文件。/usr/local管理员手动编译安装的软件的默认前缀。比如我自己编译 Python通常会指定./configure --prefix/usr/local/python3这样安装出来的东西都归/usr/local管跟系统自带的/usr/bin/python3互不干扰。/usr/src内核源码或部分软件源码的存放位置编译内核时经常会看到它。这里最关键的一点是/usr虽然名字有 user 这三个字母但它跟“用户自己放文件”没有关系。用户自己的文件放在/home系统软件放在/usr配置放/etc日志丢/var这几个流向要分清楚。/usr里那么多子目录十有八九都是给“包管理器安装的软件”和“编程库”用的。/usr/local则是我个人平时很喜欢的一个目录。为什么要特意把手动编译的软件装进/usr/local因为包管理器升级系统软件时不会去碰/usr/local你编译安装的东西就不会在apt upgrade或yum update时被莫名替换掉。反过来包管理器自己的文件都在/usr也不会跟你手动装的东西互相污染。2.3 /lib 与动态链接库的依赖关系/lib存放的是系统启动和/bin、/sbin中命令运行时必需的动态链接库文件扩展名一般是.so类似于 Windows 里的.dll。在现在多数发行版里/lib、/lib64往往是指向/usr/lib、/usr/lib64的软链接。动态链接库是 Linux 程序运行的重中之重。一个程序在编译时可能链接了几十个.so文件运行时如果缺了某个库程序就会报错。最经典就是那个错误error while loading shared libraries: libxxx.so.1: cannot open shared object file: No such file or directory遇到这种报错第一反应不是去下载一个同名.so文件乱丢而是要先搞清哪个程序需要它。排查手段是用ldd查看程序依赖的库ldd /usr/bin/nginx输出会列出 nginx 依赖的所有.so、已经通过哪个路径找到或没找到。如果某个库显示not found就需要安装对应的软件包来补库而不是自己从网上随便下载。库文件位置不对、版本不匹配引发的连锁问题比想象中多得多。LD_LIBRARY_PATH这个环境变量也要知道它可以额外指定程序搜索动态库的路径。但它不能滥用用过头容易让系统程序加载到错误版本的库。遇到依赖问题优先用包管理器安装-devel或-libs包次选用LD_LIBRARY_PATH临时指定最后才考虑手动链接。2.4 实战用 which、ldd 排查命令和库的依赖理解了这些目录的分工排查问题就有了抓手。比如你在终端敲python系统到底执行了哪个 python用which或type看一眼which python type pythonwhich显示的是 PATH 路径下找到的可执行文件完整路径。如果同时装了系统自带的 Python 和手动编译的 Python经常会出现“敲 python 进的是 3.8但以为自己在用 3.11”的情况。看完which再决定改 PATH 还是改软链接就不会乱了。下面这张表可以帮你快速分清可执行文件的存放逻辑路径内容使用者典型例子/bin系统启动和基础操作命令所有用户ls, cp, mv, bash/sbin系统管理命令主要是 rootfdisk, mkfs, iptables/usr/bin绝大多数软件命令所有用户python3, nginx, git/usr/sbin系统服务管理命令主要是 rootuseradd, groupadd/usr/local/bin手动编译软件的默认命令位置所有用户自定义脚本、自编译软件/opt/bin独立第三方软件的启动脚本随软件而定部分商业软件3. /etc配置文件的家也是定位故障的第一现场3.1 /etc 里到底躺着哪些关键文件/etc是 et cetera等等的缩写但实际上它是整个 Linux 系统的“配置中心”。几乎每个核心组件的配置文件都能在/etc下找到这也是故障排查时第一个要翻的目录。几个我日常尝鲜型的重点配置文件/etc/passwd用户账户的基本信息每行一个用户格式为用户名:x:UID:GID:注释:家目录:登录Shell。别看它叫 passwd但真正存储密码散列值的是/etc/shadow/etc/passwd里的 x 只是占位。/etc/shadow加密后的用户密码信息和密码有效期策略只有 root 能读。忘了 root 密码时很多修复方法就是在单用户模式下改这个文件。/etc/group用户组定义。/etc/fstab开机自动挂载表。系统启动时会按这个文件的分区、挂载点、文件系统类型、挂载参数一行行自动挂载。改错 fstab 会导致系统起不来所以修改前一定要备份。/etc/hosts本地主机名到 IP 的静态映射。优先级高于 DNS做本地开发环境域名解析时经常改它。/etc/resolv.confDNS 配置。但注意在很多发行版里它可能是由 NetworkManager 或 systemd-resolved 动态生成的你直接改这个文件重启网络服务后可能被覆盖。/etc/profile和/etc/bashrc全局环境变量和 Shell 配置对所有用户生效。个人配置则放在用户家目录下的.bashrc、.profile里。/etc/sudoerssudo 权限控制表。要改必须用visudo命令不能用编辑器直接乱改改坏了会导致所有用户都没法 sudo。/etc/nginx/nginx.conf、/etc/ssh/sshd_config、/etc/mysql/my.cnf这些是各软件自己的配置文件全都归在/etc下的同名子目录或同名文件里。3.2 配置文件的“只读”错觉与动态生成文件新手最容易栽的跟头是以为/etc下的文件都是“手写的、稳定的”。实际上很多文件是程序动态生成的最典型的就是/etc/resolv.conf。你有一次手动改了/etc/resolv.conf把 DNS 换成114.114.114.114以为万事大吉。结果服务器一重启或者网络管理器做了一次更新这个文件又变回了原来的内容或者变成一个软链接指向/run/systemd/resolve/stub-resolv.conf。原因在于现在很多发行版的网络栈由 NetworkManager 或 systemd-resolved 接管他们启动时会根据自己数据库中的配置重新生成这个文件。正确做法是去 NetworkManager 的配置里改 DNS而不是直接碰/etc/resolv.conf。另一个典型是/etc/machine-id它由 systemd 生成记录机器的唯一 ID一般不要去改。还有/etc/adjtime它是系统时间漂移校正用的。这些文件虽然躺在“静态配置目录”里但内容实际上是程序在维护的。所以看到一个/etc文件时先问一句这个文件是“源配置”还是“生成结果”如果是生成结果直接改意义不大甚至会被覆盖。判断方法也不难ls -l看它是不是软链接再查对应软件的管理机制基本就有数了。3.3 实战改配置前先备份这些环节最容易翻车在/etc下动刀我给自己定过几条铁律这几年帮我躲过不少坑改之前先备份备份带上时间戳。最简单的做法就是cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.20250120。注意别用同一个.bak名反复覆盖否则改到第二天想出问题连回退文件都跟上一次备份混了。能用语法检查就先检查。nginx 有nginx -tsshd 有sshd -tBIND 有named-checkconf。改完配置、重载服务之前先跑一遍语法检查很多低级错误就能避免。远程改配置要给自己留后路。长时间 SSH 连接服务器改配置有一个很实用的技巧改完不要马上退出先开一个新终端测试服务是否正常确认没问题再断开。如果改坏了要立刻回退千万不要一边退 SSH 一边祈祷服务能起来——十次里有八次是回不去的。重载服务而非重启服务器。大部分配置改了之后只需要systemctl reload 服务名就能生效例如systemctl reload nginx。它比restart更温和不会造成连接中断。但有些配置必须重启才能生效比如内核参数改动那就老老实实重启对应服务或主机。4. /home 与 /var用户数据与动态数据的存放逻辑4.1 /home 下每个用户一个家权限怎么分/home是普通用户的家目录所在地路径一般是/home/用户名。为什么每个用户都要有一个独立的“家”因为家目录承载着用户个人的配置、文件、脚本、环境变量。你登录系统后默认的工作目录就是自己的家目录用cd ~或cd $HOME可以快速跳回去。家目录里那些以点开头的隐藏文件.bashrc、.bash_profile、.gitconfig、.ssh其实比表面看起来重要得多。用户的个性化 Shell 配置、软件授权信息、密钥文件全在这里。这也是为什么在创建新用户时通常会用useradd -m加上-m参数让系统同时创建一个完整的家目录骨架并在里面铺好默认的.bashrc等模板文件。权限方面/home下的每个目录默认只有目录所有者能读写。如果你用 root 往别人家目录里塞了文件但文件 owner 是 root普通用户可能反而改不了这就是权限模型的常见困扰。所以“家目录归用户所有”不仅是一个规范更是安全边界。还有一个很多人忽略的点root 的家目录不在 /home而在 /root。这是因为 root 是系统的超级管理员它的家目录必须独立出来避免普通用户因某些权限问题接触到 root 的环境。4.2 把 /home 挂到独立分区什么时候做、怎么做把/home独立成一个分区是服务器部署中最常见的分区规划之一。核心原因有两个数据安全隔离系统分区/出问题重装系统时独立分区的/home数据不受影响。只要重装时不格式化/home用户数据就能保留。容量管理灵活某个用户的数据量暴涨不会因为挤爆了/分区而拖垮整个系统反过来系统分区也能保持相对于净避免乱七八糟的东西占用根分区空间。有多台生产服务器之后你会越来越认同“/home 和 / 分开”这个做法。我自己曾经在一台只分了一个根分区的机器上跑服务结果用户上传的数据把/塞满了数据库直接写入失败排查好久才发现是/home和/共用一块盘的锅。如果服务器已经用了很久/home没有独立分区现在想迁移也不是没有办法。思路是先把数据拷贝到新分区再修改挂载配置。大致步骤如下把新分区格式化后临时挂载到一个目录比如/mnt/newhome。用rsync -av /home/ /mnt/newhome/拷贝现有数据。rsync比cp更擅长做这类同步因为它可以保留权限、属主、软链接还能断点续传。修改/etc/fstab把新分区挂载到/home然后重启或mount -a。这里有个关键技术点拷贝数据一定要保留属主和权限否则用户登录后家目录权限乱了SSH 甚至可能拒绝登录。所以 rsync 里-aarchive选项几乎是必选的。迁移完成之后别急着删旧数据先在系统跑到稳定状态、确认新分区正常再做清理。4.3 /var日志、缓存、锁文件都在这里膨胀/var的 var 是 variable可变的意思专门存放系统运行过程中不断变化的数据。这是整个根目录里最“活”的一个目录也是最容易把磁盘塞满的目录之一。/var下面值得重点关注的子目录/var/log系统日志大本营。syslog、messages、secure、audit、各应用自己的日志目录都在这里。/var/lib数据库和应用程序的状态目录。比如 MySQL/MariaDB 的数据文件默认在/var/lib/mysqlPostgreSQL 在/var/lib/postgresqlDocker 的容器数据在/var/lib/docker。这个目录容量通常增长非常快也是“磁盘被写满”的重灾区。/var/cache软件包管理器和应用程序的缓存。比如apt下载的.deb包、yum的缓存都会在这里。/var/spool待处理的任务队列比较典型的是邮件队列、cron 任务队列、打印队列。/var/tmp系统重启后依然保留的临时文件和/tmp不一样/tmp重启后会清空/var/tmp则会随着系统持续运行而保留适合放一些“需要跨重启但只是临时用”的文件。还有一个很关键的细节/var/run在几乎所有现代发行版里都是指向/run的软链接而/run是 tmpfs 文件系统它占用内存而不是磁盘空间所以重启后内容会丢失。很多新手在/var/run下创建目录来放进程 PID 文件或 socket系统一重启又消失就是这个原因。相关服务要么通过 systemd 的 RuntimeDirectory 管理要么在服务启动时自动创建目录。4.4 实战/var 被写满的排查链路“/var 把磁盘塞满”是我在服务器运维中遇到过不下十次的经典问题典型症状是服务报错“No space left on device”但用df -h一看使用率也不是 100%或者明明删了文件可用空间却没有明显增加。出现这种情况排查思路有固定的链路我按顺序走一遍第一步用df -h确认到底是哪个挂载点满了。因为前面说过/home、/var可能跟/是分开的分区所以“根分区满了”和“/var 分区满了”是两个不同的故障。第二步用du -sh /var/* 2/dev/null | sort -hr查看/var下每个子目录的体积快速定位是哪个目录在膨胀。第三步如果是/var/log体积夸张多半是某个服务疯狂打日志。不要直接rm -rf /var/log/*了事因为日志文件可能正被进程占用删除后空间也不会立即释放这在 Linux 上是经典问题删了文件但进程还持有文件句柄df -h依旧显示磁盘满。正确处理是先定位写日志的进程重启或 reload 它让文件句柄释放再考虑清理日志。如果是journald系统日志服务占用过大用journalctl --vacuum-size200M可以把它压缩到 200M 以内比手动删 journal 文件安全得多。第四步如果是/var/lib/docker撑爆磁盘别再手贱删容器里的文件而是考虑迁移整个 Docker 数据目录或定期跑docker system prune -a清理无用的镜像和构建缓存。第五步如果是/var/lib/mysql这类数据库目录千万别直接删文件——那是销毁数据。正确做法是清理 binlogPURGE BINARY LOGS、清理无用的分表或者扩展磁盘。5. /dev、/opt、/tmp、/mnt平时不起眼出事很要命5.1 /dev设备也是文件这就是“一切皆文件”/dev目录是“一切皆文件”哲学的极致体现。磁盘、分区、键盘、终端、随机数生成器……在 Linux 里都被抽象成了文件统一放在/dev下。你有lsblk或者fdisk -l时看到的sda、sdb、nvme0n1它们对应的设备文件就是/dev/sda、/dev/sda1、/dev/nvme0n1p1。这些设备文件不是你手动创建的而是系统启动时由 udev 这个守护进程自动探测硬件然后生成的。除了磁盘设备/dev里还有几个“虚拟设备”经常被脚本用到/dev/null黑洞文件。任何写入它的数据都被丢掉常用在命令行里屏蔽不需要的输出比如command 2/dev/null。/dev/zero源源不断产生零字节的文件常用来生成指定大小的全零文件。/dev/random和/dev/urandom随机数生成器常用于加密、生成密钥等场景。/dev/tty*终端设备文件。做磁盘测试时会经常用到/dev/urandom来生成随机数据写入文件或者用/dev/zero快速生成大文件来测试磁盘写入速度。但注意这只会对设备文件做写入操作时要极其谨慎选错了设备可能直接抹掉整个磁盘数据。日常生产环境里不到万不得已不要对sdX这种整个磁盘的设备做dd写操作。5.2 /opt第三方软件的落脚点/opt是 optional可选的的缩写专门留给“独立第三方软件”使用的目录。那么问题来了一个软件装在/usr/bin和装在/opt有什么区别为什么要把某些软件放到/opt我自己的理解是/usr是“系统包管理器统一管理的软件”的地盘而/opt是“自带完整目录结构的、独立发布的软件”的地盘。很多商业软件、闭源软件、或者自带依赖库的软件都喜欢装进/opt。比如 Oracle、某些 IDE、一些企业级监控 Agent它们通常会在/opt/软件名下建立一个完整的目录树把二进制、库、配置文件、数据都放在里面做到“自带一套、互不干扰”。和/usr/local的区别在于/usr/local更偏向“我自己手动编译安装的源码软件”文件的摆放会更分散bin 归 bin、lib 归 lib而/opt下通常是某个软件的完整独立目录想要卸载往往直接删对应目录即可。所以看到/opt/xxx时你大致能猜到这是一个“自带家的第三方软件”。如果磁盘空间紧张优先考虑清理/opt下已经不用的软件目录会比在/usr里乱删文件安全得多。5.3 /tmp 的特殊权限与安全陷阱/tmp是系统临时文件目录它背后有一个非常有意思的权限设计叫做sticky bit。用ls -ld /tmp查看权限位最后是tdrwxrwxrwt 20 root root 4096 Jan 20 10:23 /tmp这个t表示任何人都有权限往/tmp里写文件但你写进来的文件只有你自己或 root才有权限删除。这既保证了/tmp的开放性又防止了普通用户恶意删除别人的临时文件。如果哪天你的一个临时文件放在/tmp下别人能看到或删掉它多半就是权限出了问题或者文件被放在了别的权限不当的目录。使用/tmp有一条铁律不要在里面放重要数据。系统重启时systemd-tmpfiles 会按策略清理/tmp下超过一定时间的文件很多发行版甚至直接用 tmpfs 挂载/tmp直接把临时文件放在内存里速度极快但断电即失。所以任何需要长期保存的东西都不该出现在/tmp。5.4 /proc 与 /sys不复盘目录它们在内存里严格来说/proc和/sys在标题里没有出现但它们实在太常被忽略了。这俩目录不是真实存在于磁盘上的文件夹而是内核提供的虚拟文件系统内容在内存里实时生成。/proc进程和系统信息。每个运行中的进程在/proc/进程PID下都有对应目录里面放着进程的环境变量、打开的文件、内存映射等数据。/proc/cpuinfo、/proc/meminfo也是排查系统资源时的高频文件。/sys内核设备模型和驱动信息比/proc更偏向设备和内核模块。很多内核参数可以在/sys下修改但通常更推荐用sysctl命令来管理。这两个目录都是虚拟的你往里写数据往往毫无意义甚至可能造成系统状态不一致。排查问题用它们来“读”信息是没问题的比如cat /proc/cpuinfo | grep processor看有几个核但“向/proc或/sys写东西”要慎之又慎除非你完全清楚自己在做什么。6. 综合排错这些热搜里的 Linux 目录问题到底怎么解决6.1 /var/lib/dpkg 锁文件与 apt 卡死很多用 Debian/Ubuntu 系的用户都遇到过“Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend”这个报错。这个问题本质是 apt/dpkg 在运行时会锁定/var/lib/dpkg/下的锁文件防止多个包管理进程同时操作数据库。如果你已经开了一个终端在装软件另一个终端再执行 apt 就会等锁。遇到这个提示第一步用ps aux | grep -E apt|dpkg看是否有后台 apt 进程在跑。如果确实有等它完成即可。如果只是残留的僵死进程sudo kill掉再执行sudo dpkg --configure -a修复。千万不要一上来就rm -rf /var/lib/dpkg/lock-frontend强行删锁文件如果恰好有另一个 apt 正在写数据库删锁会导致 dpkg 数据库损坏那才是真正的灾难。删锁永远是最后手段而且删完还要确认没有残留进程。这个案例也给了一个启示/var/lib下的文件是应用状态的核心乱动它的风险远超省下的那点时间。6.2 把 /var/lib/docker 挪到其他盘“是否可以将 /var/lib/docker 移动到 /data/docker 中会不会影响 docker 的运行”这个问题在搜索记录里出现过很多次。我的回答是可以Docker 官方就支持改数据目录但操作方式要对。最稳妥的方式是修改 Docker 的配置文件让 Docker 启动时使用新的数据根目录。以 systemd 管理的环境为例停止 Docker 服务sudo systemctl stop docker。用rsync -av /var/lib/docker/ /data/docker/把现有数据完整拷贝过去。注意目录末尾的斜杠同步时务必保留权限和属主。编辑/etc/docker/daemon.json如果没有就新建写入{ data-root: /data/docker }sudo systemctl start docker然后用docker info查看Docker Root Dir是否变成了新路径。有人图省事直接mv /var/lib/docker /data/docker后做软链接ln -s /data/docker /var/lib/docker这种方案在旧版本 Docker 上可能能撑一阵但新版本对目录搬移时的权限和挂载要求更细不推荐在生产环境里这样搞。用 daemon.json 指定>sudo mkdir -p /var/run/mysqld sudo chown mysql:mysql /var/run/mysqld sudo systemctl start mysqld不过更好的做法是让服务通过 systemd 的RuntimeDirectorymysqld自动管理这样每次启动都会自动创建/run/mysqld并设置合适的权限不用每次重启后都手动补一刀。看到这个报错时别再怀疑配置写错了先检查目录在不在。6.4 分区规划的最终建议聊了这么多目录最后落到一个非常实际的问题装系统或者买新服务器时分区到底怎么规划个人开发机或者虚拟机其实不需要搞太复杂一个根分区加一个 swap 就够了。但生产服务器最好做好隔离/boot独立分区容量 1G 左右就够内核和引导文件放这里。/系统根分区建议 50G 以上装系统软件和/usr用。/home独立分区按用户数据量规划。/var有条件就独立分区日志、数据库、容器数据都可能在短时间内暴涨独立分区可以防止它拖垮根分区。swap内存的兜底物理内存大可以设小一点或者直接不设。如果以后有大量 Docker 场景我会直接强调Docker 数据目录所在的分区一定要大因为镜像、容器层、卷数据加起来膨胀非常快。提前把/var/lib/docker或自定义的>