Docker: montages refusés. Les chemins… ne sont pas partagés depuis OS X et ne sont pas connus de Docker

La commande docker run -v /var/folders/zz/...produit l'erreur suivante.

docker: Error response from daemon: Mounts denied: 
The paths /var/folders/zz/... and /var/folders/zz/...
are not shared from OS X and are not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.

Lorsque j'ouvre le partage de fichiers, je vois que / private est déjà répertorié.

Si j'essaie d'ajouter /var/folder/, cela résout /private/var/folders, qui est un sous-ensemble de / private et donc l'ajout est rejeté.

Pour résumer, il me semble que le répertoire /var/folders/..est partagé par OS X en tant que sous-répertoire de /privateet doit donc être connu de Docker. Toute aide pour résoudre ce problème serait appréciée.

À titre expérimental, j'ai remplacé le /privatepartage de fichiers par /private/var/folderset redémarré le menu fixe, mais le résultat n'a pas changé.

Juste pour une référence plus complète, voici le script .sh , qui exécute ce script python , qui à son tour exécute la commande docker.

Les montages de volume Docker pour Mac se comportent différemment du système Docker de base. Ceci est principalement dû au fait que Docker tente de se conformer aux directives du sandbox du système de fichiers d'Apple.

Comme indiqué dans les préférences de Docker, seuls certains chemins sont exportés par macOS.

• /Users
• /Volumes
• /tmp
• /private

/vardans macOS est un lien symbolique vers /private. Cela est également vrai pour /tmp:

$ ls -ld /tmp /var
lrwxr-xr-x@ 1 root  wheel  11 Jan 26 16:18 /tmp -> private/tmp
lrwxr-xr-x@ 1 root  wheel  11 Jan 26 16:18 /var -> private/var

Pourquoi est /tmprépertorié dans le panneau de partage, mais /varne l'est pas (même si les deux en font partie /private)? La documentation de Docker pour Mac sur les espaces de noms des systèmes de fichiers explique:

Par défaut, vous pouvez partager des fichiers dans /Users/, /Volumes/, /private/et /tmpdirectement. Pour ajouter ou supprimer des arborescences de répertoires exportées vers Docker, utilisez l'onglet Partage de fichiers dans le menu baleine des préférences de Docker -> Préférences -> Partage de fichiers. (Voir Préférences.)

Tous les autres chemins utilisés dans les -vmontages de liaison proviennent de la machine virtuelle Moby Linux exécutant les conteneurs Docker, de sorte que les arguments tels que -v /var/run/docker.sock:/var/run/docker.sockdevraient fonctionner comme prévu. Si un chemin macOS n'est pas partagé et n'existe pas dans la machine virtuelle, une tentative de liaison de montage échouera plutôt que de le créer dans la machine virtuelle. Les chemins qui existent déjà dans la machine virtuelle et contiennent des fichiers sont réservés par Docker et ne peuvent pas être exportés depuis macOS.

Notez que cela /var/runest spécifiquement mentionné ici comme un endroit qui serait monté à partir de la machine virtuelle Linux, au lieu de macOS.

Lorsque vous demandez un montage de volume, les exportations du système de fichiers macOS sont vérifiées en premier. S'il n'y a pas de correspondance, la machine virtuelle Linux sur laquelle Docker est exécuté est ensuite vérifiée. Si aucun d'eux n'a le chemin que vous avez demandé, le montage échoue.

Dans votre cas, /varn'est pas exporté par macOS. /varexiste dans la machine virtuelle Linux, mais /var/folderspas. Par conséquent, le chemin d'accès n'est pas disponible et le montage échoue.

Si vous modifiez le chemin vers /private/var, cela réussira, car macOS exporte l'intégralité de l' /privatearborescence du système de fichiers pour le montage.

Afin de rendre les choses plus portables, vous voudrez peut-être tester la plate-forme sur laquelle vous utilisez actuellement, et s'il s'agit de macOS, préfixez le chemin de montage avec /private.

Comme solution alternative :

Changer le chemin de /private/instance1-data:/homeà./instance1-data:/home

Dans le pays * nix et par conséquent, Docker, le .indique le répertoire actuel. Étant donné que macOS est difficile et devient encore plus sélectif en matière de sandboxing, cela semble être une solution viable pour macOS. Créez simplement le dossier nécessaire instance1dans le même répertoire.

Un autre avantage de cette solution est qu'elle supprime le besoin de courir docker-composeavec sudo. Quoi qu'il en soit, cela ne cause aucun mal dans ce cas, mais c'est quand même un plus.

À titre d'exemple, en utilisant Portainer, cette commande fonctionne pour moi:

docker run -d --restart unless-stopped -p 9000:9000 \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /var:/data portainer/portainer --no-auth

Mais, si je change le -v /var:/datadu tout, cela ne fonctionnera pas. Je pense (mais pas sûr) que c'est parce que Docker essaie de faire un mkdir. Donc, si j'essaye de monter -v /var/whatever:/data, mkdir échoue car pas assez de permission, et ça ne marche pas.

J'ai 2 Mac (High Sierra) et je l'ai essayé sur les deux. Même problème. De plus, j'ai essayé d'utiliser le canal Docker Beta. Je pense que je comprends la réponse de Dan Lowe: je mettrai à jour cette réponse si cela fonctionne pour moi.

J'ai eu un problème similaire où j'avais créé un répertoire /var/tmpdans mon Mac que je voulais monter dans mon conteneur docker.

Résolu le problème en ajoutant le chemin du répertoire à un fichier comme suit:

$ cat ~/Library/Group\ Containers/group.com.docker/settings.json  
{
  "filesharingDirectories" : [
    "\/Users",
    "\/Volumes",
    "\/private",
    "\/tmp",
    "\/var\/tmp"
  ],
…

Maintenant, je pouvais voir le répertoire /var/tmpdans Docker-> préférence-> ressources-> partage de fichiers. Ensuite, j'ai redémarré le docker.

Cela a ensuite résolu mon problème de montage.