erreur lors de la création d'un montage de superposition sur un montage nfs

1. overlay2 est le pilote de stockage par défaut, mais comme vous pouvez le voir dans documentation du pilote de stockage docker , n'est valide que pour xfs avec ftype = 1, ext4 Peut-être que votre / u01 / docker est dans un autre système de fichiers.

2. Si votre / u01 / docker est un xfs de type ftype = 1 ou ext4, vérifiez que les selinux sont désactivés.

Afin de vérifier que le système de support est compatible avec votre overlay2, vous pouvez exécuter:

$ docker info

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

Vous ne devriez vraiment pas exécuter docker avec un serveur NFS comme système de fichiers de sauvegarde. Même si vous pouviez le faire fonctionner, cela serait lent et le problème de la distribution d'images à plusieurs hôtes a déjà été résolu avec les serveurs de registre et les couches réutilisables.

Le système de fichiers overlay2 lui-même est documenté comme nécessitant xfs avec ftype = 1 ou ext4 comme système de fichiers de sauvegarde, pas NFS.

Là où vous pouvez utiliser NFS, c'est avec les volumes montés dans des conteneurs pour les données persistantes. Ces volumes existeraient en dehors du conteneur et ne seraient pas enregistrés dans le registre, il est donc logique de les pousser vers NFS. Voici quelques exemples de différentes manières de monter un volume avec 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"
  ...

Dans mon cas, la solution de contournement était étonnamment de restreindre le nombre de commandes / couches de construction du docker 'RUN', car si le nombre dépassait 60 couches / commandes, cela se terminait toujours par l'erreur de dossier 'fusionné' manquante, peu importe quel était le contenu de la commande, même une simple commande telle que RUN ls -la a abouti à cette erreur, si le nombre total de telles commandes était supérieur à environ 60, étrange. Le sous-dossier fusionné était toujours manquant, même si même lorsque j'ai généré automatiquement tous les sous-dossiers fusionnés, il était toujours créé à la volée une nouvelle couche avec un nouveau hachage, qui manquait ce sous-dossier.