不能直接用 docker exec 对容器内部磁盘挂载点做热扩容，因为容器不管理底层块设备或文件系统大小，docker exec 也无法修改宿主机分区、逻辑卷或挂载参数；可行方案是扩容宿主机挂载目录的文件系统，或迁移 docker 根目录至更大磁盘。
不能直接用 docker exec 对容器内部磁盘挂载点做热扩容。这个操作在技术上不可行，原因很明确：容器本身不管理底层块设备或文件系统大小，它只是运行在宿主机上的进程集合，其“磁盘”本质是宿主机上某个目录（如 /var/lib/docker/overlay2/...）或绑定挂载的路径。而 docker exec 只能执行容器命名空间内的命令，无法修改宿主机的分区、逻辑卷或挂载参数。
真正可行的热扩容路径
所谓“不中断生产服务”的扩容，必须绕开容器内部，聚焦宿主机层的存储管理：
-
对容器挂载的宿主机目录扩容：如果容器通过
-v /data:/app方式绑定了宿主机目录，只需扩容该宿主机路径所在文件系统（如/data所在的/dev/sdb1），再用resize2fs或xfs_growfs调整文件系统大小——整个过程不影响正在运行的容器读写该目录。 -
迁移 Docker 根目录到更大磁盘：停 Docker 服务时间极短（通常 /etc/docker/daemon.json 中的
"data-root"，重启即可。旧数据完整保留，业务容器自动加载，感知不到中断。 -
LVM 逻辑卷在线扩展：若
/var/lib/docker位于 LVM 逻辑卷上，可先扩 LV（lvextend），再扩文件系统（resize2fs或xfs_growfs），全程无需停 Docker 服务。
为什么 docker exec 不起作用
在容器里执行 df -h 看到的根分区大小，反映的是底层存储驱动（如 overlay2）所用的宿主机文件系统容量，不是容器独占的“虚拟磁盘”。你无法在容器内运行 fdisk、lvcreate 或 resize2fs 来改变它——这些工具要么缺失，要么没有权限访问宿主机设备节点，更没有对应设备文件可供操作。
替代方案：运行时挂载新存储
若需为容器临时增加空间，可在不停机前提下动态挂载新目录：
- 在宿主机准备新目录（如
/mnt/ext_disk），确保已挂载且有读写权限； - 使用
docker update --mount type=bind,source=/mnt/ext_disk,target=/app/data --restart=always 容器名（Docker 20.10+ 支持）； - 或直接
docker exec -it 容器名 mkdir -p /app/data，再由应用自行将大文件写入该路径。
关键提醒
所有真正有效的扩容都发生在宿主机层面。任何试图在容器内“扩容磁盘”的操作，本质上都是误解了容器存储模型。优先检查 df -hT /var/lib/docker 和 docker info | grep "Root Dir\|Storage Driver"，明确当前存储位置和类型，再选择对应扩容策略。
