error creating overlay mount to a nfs mount

user_5771561 0
Viewed 7856

I am using docker version 17.05.0.

Instead of using the Docker Root Dir: /var/lib/docker, I am using a directory /u01 which is mounted on the VM using an NFS share.

Docker Root Dir: /u01/docker

Storage Driver: overlay2

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

Now when I am starting the daemon, the docker pull command is working fine but when I am trying to build an image, its throwing the following error:

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

Not sure what's wrong here.

docker
3 Answers

Let's consider a couple of things:

  1. overlay2 is the default storage driver, but as you can see in docker storage driver documentation, is valid only for xfs with ftype=1, ext4 Maybe, your /u01/docker is in another filesystem.

  2. If your /u01/docker is a xfs with ftype=1 or ext4 type, check selinux are disabled.

In order to check backing system is compatible with your overlay2, you can execute:

$ docker info

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

You really should not be running docker with an NFS server as the backing filesystem. Even if you could get it to work, it would be slow and the problem of distributing images to multiple hosts has already been solved with registry servers and reusable layers.

The overlay2 filesystem itself is documented as requiring xfs with ftype=1 or ext4 as the backing filesystem, not NFS.

Where you can use NFS is with the volumes mounted into containers for persistent data. These volumes would exist outside of the container and would not be saved to the registry, so pushing those to NFS makes sense. Here's a few examples of different ways to mount a volume with 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"
  ...
user_5962850

In my case, the workaround surprisingly was to restrict the number of 'RUN' docker building commands/layers, since if the number surpassed 60 layers/commands, it always ended up with that missing 'merged' folder error, no matter what was the contents of the command, even simple command such as RUN ls -la ended up with that error, if the total number of such/any commands was higher than about 60, strange. Merged subfolder was always missing, though even when I automatically generated all the merged subfolders, always was created on the fly a new layer with a new hash, which was missing that subfolder.

user_34195350
Related