Docker 创建到nfs装载的覆盖装载时出错

我使用的是docker版本17.05.0

我没有使用Docker根目录：

/var/lib/Docker

，而是使用一个目录

/u01

，它使用NFS共享装载在VM上

Docker根目录：/u01/Docker

存储驱动程序：overlay2

# cat daemon.json
{
  "data-root": "/u01/docker",
  "storage-driver": "overlay2"
}

现在，当我启动守护程序时，docker pull命令工作正常，但当我尝试构建映像时，它抛出以下错误：

Step 2/14 : MAINTAINER RK
error creating overlay mount to /u01/docker/overlay2/f5aebc4aa90797ccfab90bfb17a44314041b4694b26aa5a1e82eba95384f9924-init/merged: invalid argument

---

不确定这里出了什么问题

overlay2是默认的存储驱动程序，但正如您在中所看到的，它仅对ftype=1、ext4的xfs有效 也许，您的

/u01/docker

位于另一个文件系统中

如果您的

/u01/docker

是ftype=1或ext4类型的xfs，请选中禁用selinux

为了检查支持系统是否与您的overlay2兼容，您可以执行：

$ docker info

Containers: 0
Images: 0
Storage Driver: overlay2
 Backing Filesystem: xfs
<output truncated>

$docker info
货柜：0
图片：0
存储驱动程序：overlay2
备份文件系统：xfs

您确实不应该使用NFS服务器作为备份文件系统来运行docker。即使您可以让它工作，它也会很慢，而且通过注册表服务器和可重用层，将图像分发到多个主机的问题已经得到了解决

overlay2文件系统本身被记录为需要ftype=1或ext4的xfs作为备份文件系统，而不是NFS

可以使用NFS的地方是将卷装载到容器中以获取持久数据。这些卷将存在于容器之外，并且不会保存到注册表中，因此将它们推送到NFS是有意义的。以下是使用NFS装载卷的几种不同方法的示例：

  # create a reusable volume
  $ docker volume create --driver local \
      --opt type=nfs \
      --opt o=nfsvers=4,addr=nfs.example.com,rw \
      --opt device=:/path/to/dir \
      foo

  # or from the docker run command
  $ docker run -it --rm \
    --mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=nfs.example.com\",volume-opt=device=:/host/path \
    foo

  # or to create a service
  $ docker service create \
    --mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=nfs.example.com\",volume-opt=device=:/host/path \
    foo

  # inside a docker-compose file
  ...
  volumes:
    nfs-data:
      driver: local
      driver_opts:
        type: nfs
        o: nfsvers=4,addr=nfs.example.com,rw
        device: ":/path/to/dir"
  ...

---

在我的例子中，解决方法是限制“运行”docker building命令/层的数量，因为如果数量超过60层/命令，则总是会出现缺少的“合并”文件夹错误，无论命令的内容是什么，即使是像

RUN ls-la

这样的简单命令也会出现该错误，如果这样/任何命令的总数超过60个，那就奇怪了<代码>合并的子文件夹始终缺失，尽管即使我自动生成了所有合并的子文件夹，也始终会动态创建一个新层，其中包含一个新的哈希，该哈希缺少该子文件夹。

是否检查了selinux是否已禁用？你能补充更多细节吗？哪些命令使用了您来解决它？这是一个解决方法，意味着如果您在dockerfile中的命令/单词“RUN”的次数超过60次，它就会停止工作，因此我在文件中有60多个RUN命令时解决了它，我将60个run命令通过连续的命令转换成30个命令，因此两个run命令

run ls-la

，

run date

我合并成一个单独的run命令，就像这样

run ls-la&&date

感谢@Evan Carrol对“工作区”的语法更正，听起来像trusim，尽管它是打字的缩写，“对我来说，工作方法是一种变通方法”，即使你打字时说它是多余的。“非工作性的解决方法”如何成为有价值的贡献