docker容器内的overlayfs答案

【问题标题】：overlayfs inside docker containerdocker容器内的overlayfs
【发布时间】：2023-03-27 19:15:01
【问题描述】：

是否可以在（特权）docker 容器中安装覆盖 fs？至少我的直观方法（在容器外运行良好）失败了：

> mkdir /tmp/{up,low,work,merged}
> mount -t overlay overlay -o lowerdir=/tmp/low/,upperdir=/tmp/up/,workdir=/tmp/work/ /tmp/merged/
mount: /tmp/merged: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.

附加信息：

Docker 版本 18.09.1，构建 4c52b90
内核 4.19.0-8-amd64
Debian 10（主机和 docker-image）

【问题讨论】：

标签： docker overlay unionfs overlayfs

【解决方案1】：

找到了一些有用的东西！将 workdir 和 upperdir 挂载为 tmpfs 对我有用。像这样：

> mkdir /tmp/overlay
> mkdir /tmp/{low,merged}
> mount -t tmpfs tmpfs /tmp/overlay
> mkdir /tmp/overlay/{up,work}
> mount -t overlay overlay -o lowerdir=/tmp/low/,upperdir=/tmp/overlay/up/,workdir=/tmp/overlay/work/ /tmp/merged/

我仍然有兴趣解释为什么在 docker 容器中创建不带 tmpfs 的覆盖失败？

【讨论】：

AFAIK 这是因为 overlayfs 仅支持单个读/写层（所有其他层必须是只读的）。由于 Docker 容器本身依赖于overlayfs（一个读/写层），因此您不能嵌套另一个读/写层。

【解决方案2】：

如何在 docker 容器中挂载 overlayfs：

https://gist.github.com/detunized/7c8fc4c37b49c5475e68ef9574587eee

基本上，您需要使用 --privileged 或更安全的 --cap-add=SYS_ADMIN 运行容器。

【讨论】：

【解决方案3】：

这有点猜测，但我怀疑这是因为 docker 已经在使用 overlayfs 并且 overlayfs 拒绝使用 upperdir 作为另一个 overlayfs。

我怀疑这可能是由于whiteout files:

为了支持rm和rmdir不改下文件系统，一个覆盖文件系统需要记录在上层文件已被删除的文件系统。这是使用whiteouts完成的和不透明的目录（非目录总是不透明的）。

whiteout 被创建为具有 0/0 设备号的字符设备。当在合并目录的上层发现空白时，任何较低级别中的匹配名称被忽略，而白化本身也被隐藏了。

要删除存在于lowerdir 中的文件，overlayfs 将创建一个whiteout 文件并隐藏所有个whiteout 文件（设备号0,0）。这在逻辑上意味着您不能在 overlayfs 内创建编号为 0,0 的字符设备文件，因为必须由 overlayfs 本身隐藏。

如果您被允许将 overlayfs 用作upperdir，它将无法创建中断文件，因此无法从较低层创建rm 或rmdir 任何文件。因为它无法在另一个overlayfs上创建编号为0,0的字符设备文件。

【讨论】：