Docker容器执行debootstrap失败，挂载权限及权限配置优化求助

一、解决挂载目录的exec/dev权限限制问题 #

你遇到的错误源于挂载的主机目录默认被Docker施加了noexec（禁止执行二进制文件）和nodev（禁止创建设备文件）限制，而debootstrap需要这两类权限完成镜像构建。

修改容器启动命令中的volume挂载参数，添加exec和dev选项即可解决：

curDir=$(pwd)
mkdir -p "$curDir"/workspace
docker run \
   --volume /host_mnt/"$curDir"/workspace:/home/workspace:exec,dev,rw \
   --platform linux/amd64 \
   --privileged \
   --cap-add=ALL \
   -it \
   ubuntu /bin/bash

• exec：解除挂载目录的执行限制，允许运行二进制文件
• dev：解除挂载目录的设备创建限制，支持mknod操作
• rw：明确开启读写权限（默认已开启，添加后逻辑更清晰）

二、替代--privileged和cap-add=ALL的最小安全权限配置 #

--privileged会完全关闭容器安全隔离，cap-add=ALL赋予所有内核权限，存在极高安全风险。以下是满足debootstrap需求的最小权限配置：

必要内核能力（Capabilities） #

debootstrap仅依赖以下几个特定权限：

• CAP_MKNOD：允许创建/dev/null等设备文件
• CAP_SYS_CHROOT：支持后续chroot到目标镜像目录（--foreign模式暂不需要，但预留可避免后续阶段报错）
• CAP_SETUID/CAP_SETGID：允许切换用户权限完成文件安装操作

完整安全启动命令 #

curDir=$(pwd)
mkdir -p "$curDir"/workspace
docker run \
   --volume /host_mnt/"$curDir"/workspace:/home/workspace:exec,dev,rw \
   --platform linux/amd64 \
   --cap-add=CAP_MKNOD \
   --cap-add=CAP_SYS_CHROOT \
   --cap-add=CAP_SETUID \
   --cap-add=CAP_SETGID \
   --security-opt apparmor=unconfined \
   -it \
   ubuntu /bin/bash

• --security-opt apparmor=unconfined：Ubuntu默认的AppArmor配置会限制容器内的mknod操作，临时解除该限制（若移除后仍正常工作可省略）

验证 #

执行debootstrap --arch arm64 --foreign jammy /home/workspace/即可正常完成最小Ubuntu镜像构建。

内容的提问来源于stack exchange，提问作者jake wong