不能在容器运行时直接挂载块设备。docker 不支持向已启动的容器动态添加块设备（如 /dev/sdb）或绑定挂载新路径，因容器 mount namespace 已冻结、设备未提前暴露且缺乏 sys_admin 权限；正确做法是停止容器后用 -v 或 --mount 重新运行并挂载，或通过 nfs 等网络存储实现灵活扩展。
不能在容器运行时直接挂载块设备。Docker 不支持向已启动的容器动态添加块设备（如 /dev/sdb）或绑定挂载新路径。这是由容器隔离机制和 Linux 命名空间限制决定的——设备节点和挂载点必须在容器启动时就声明并注入。
为什么运行中无法挂载块设备
容器启动后，其 mount namespace 已冻结，/proc/mounts 和设备可见性不再接受外部新增挂载；docker exec 进入容器后执行 mount /dev/sdb1 /mnt 会失败，报错 permission denied 或 not a valid block device，因为宿主机设备未提前暴露、且容器缺乏 sys_admin 权限和对应 cgroup 设备控制权限。
正确做法：分两步完成“动态效果”
虽然不能真正在运行中挂载，但可通过重启容器快速实现等效效果，全程无需重建镜像或丢失数据：
-
第一步：确保宿主机已识别并准备设备
插上硬盘 → 运行lsblk确认设备名（如/dev/sdc1）→ 创建挂载点：sudo mkdir -p /mnt/extdisk→ 手动挂载测试：sudo mount /dev/sdc1 /mnt/extdisk -
第二步：停旧启新，复用原配置
记下原容器命令关键参数（镜像名、端口映射、环境变量等）→ 停止容器：docker stop myapp→ 用相同配置重跑，仅新增挂载：docker run -d --name myapp -v /mnt/extdisk:/data -p 8080:80 nginx -
第三步（可选）：避免手动重复
将挂载写入/etc/fstab实现开机自动挂载宿主机设备；再用docker-compose.yml统一管理容器启动参数，下次只需docker compose up -d即可同步生效
进阶：需要真正热插拔？试试特权模式 + 手动注入
极少数场景（如嵌入式调试、CI 测试），若你完全掌控宿主机且接受安全风险，可尝试以下方式（不推荐生产环境）：
- 启动容器时加
--privileged和--device /dev/sdc:/dev/sdc:rwm，让设备节点提前可见 - 进入容器：
docker exec -it myapp /bin/sh - 在容器内执行：
mkdir -p /mnt/hotplug && mount /dev/sdc1 /mnt/hotplug（前提是该设备已在宿主机上被识别且未被占用） - 注意：此操作依赖宿主机 udev 规则、容器内内核模块支持，稳定性差，且每次插拔需手动干预
替代方案：用 NFS 或 Ceph 等网络存储模拟“动态”
如果目标是灵活扩展存储而非物理硬盘直通，更可靠的方式是：
- 在 NAS 或另一台服务器上导出 NFS 共享
- 宿主机安装
nfs-common，挂载到/mnt/nfs-share - 通过
-v /mnt/nfs-share:/data挂入容器 —— 后续只需在服务端增删目录，容器内即可实时看到变化，无需重启
