Essayez-vous de monter un répertoire sur un fichier (ou vice-versa)?

J'ai un docker avec la version 17.06.0-ce. Lorsque j'essaie d'installer NGINX à l'aide de docker avec la commande:

docker run -p 80:80 -p 8080:8080 --name nginx -v $PWD/www:/www -v $PWD/conf/nginx.conf:/etc/nginx/nginx.conf -v $PWD/logs:/wwwlogs -d nginx:latest

Cela montre que

docker: réponse d'erreur du démon: erreur d'exécution oci: container_linux.go: 262: démarrage du processus de conteneur causé "process_linux.go: 339: conteneur init causé \" rootfs_linux.go: 57: montage \\ "/ appdata / nginx / conf / nginx.conf \\ "\\ "à rootfs / var / lib / docker / aufs / mnt / dcea22444e9ffda114593b18fc8b574adfada06947385aedc2ac09f199188fa0 \\" à \\" / var / lib / docker / aufs / mnt / dcea22444e9ffda114593b18fc8b574adfada06947385aedc2ac09f199188fa0 / etc / nginx / nginx.conf \\ "a causé \\" pas un répertoire \\ "\" ": essayez-vous de monter un répertoire sur un fichier (ou vice-versa)? Vérifiez si le chemin d'hôte spécifié existe et est du type attendu.

Si vous ne montez pas le nginx.conffichier, tout va bien. Alors, comment puis-je monter le fichier de configuration?

Parce que docker reconnaîtra $PWD/conf/nginx.confcomme un dossier et non comme un fichier. Vérifiez si le $PWD/conf/répertoire contient nginx.confcomme répertoire .

Tester avec

> cat $PWD/conf/nginx.conf 
cat: nginx.conf/: Is a directory

Sinon, ouvrez un problème Docker .
Cela fonctionne bien pour moi avec la même configuration.

Cela ne devrait plus arriver (depuis la v2.2.0.0), voir ici

Si vous utilisez Docker pour Windows , cette erreur peut se produire si vous avez récemment modifié votre mot de passe.

Comment réparer:

1. Assurez-vous d'abord de supprimer le volume du conteneur cassé
   docker rm -v <container_name>
   .
2. Ouvrez les paramètres Docker
3. Accédez à l'onglet "Disques partagés"
4. Cliquez sur le lien "Réinitialiser les informations d'identification ..." en bas de la fenêtre
5. Re-partager les lecteurs que vous souhaitez utiliser avec Docker

• Vous devriez être invité à entrer votre nom d'utilisateur / mot de passe

6. Cliquez sur "Appliquer"
7. Allez dans l'onglet "Réinitialiser"
8. Cliquez sur "Redémarrer Docker"
9. Recréez vos conteneurs / volumes

Le mérite revient à BaranOrnarli sur GitHub pour la solution.

TL; DR : Supprimez les volumes associés au conteneur.

Recherchez le nom du conteneur en utilisant, docker ps -apuis supprimez ce conteneur en utilisant:

docker rm -v <container_name>

Problème:

L'erreur à laquelle vous faites face peut se produire si vous avez précédemment essayé d'exécuter la docker runcommande alors que le fichier n'était pas présent à l'emplacement où il aurait dû se trouver dans le répertoire hôte.

Dans ce cas, le démon docker aurait créé un répertoire à l'intérieur du conteneur à sa place, qui échoue plus tard à mapper vers le fichier approprié lorsque les fichiers corrects sont placés dans le répertoire hôte et que la commande docker est réexécutée.

Solution:

Supprimez les volumes associés au conteneur. Si vous n'êtes pas préoccupé par les autres volumes de conteneurs, vous pouvez également utiliser:

docker volume rm $(docker volume ls -q)

Réponse pour les utilisateurs de Docker Toolbox

Il y a eu au moins 3 réponses ici touchant au problème, mais ne l'expliquant pas correctement et ne donnant pas une solution complète. C'est juste un problème de montage de dossier .

Description du problème:

Docker Toolbox contourne l'exigence Hyper-V de Docker en créant une machine virtuelle (dans VirtualBox, qui est fourni). Docker est installé et exécuté à l'intérieur de la machine virtuelle. Pour que Docker fonctionne correctement, il doit avoir accès au à partir de la machine hôte. Ce qui n'est pas le cas ici.

Après avoir installé Docker Toolbox, il a créé la VM VirtualBox et monté uniquement sur C:\Usersla machine, en tant que \c\Users\. Mon projet était C:\projectsdonc nulle part sur le volume monté. Lorsque j'envoyais le chemin vers la VM, il n'existerait pas, car il C:\projectsn'est pas monté. Par conséquent, l'erreur ci-dessus.

Disons que mon projet contient ma configuration ngnix C:/projects/project_name/

Réparer:

1. Allez dans VirtualBox, faites un clic droit sur Default (la VM de Docker)> Paramètres> Dossiers partagés

2. En cliquant sur la petite icône avec le plus sur le côté droit, ajoutez un nouveau partage. J'ai utilisé les paramètres suivants:

3. La carte ci - dessus va C:\projectsà /projects( ROOT/projects) dans la machine virtuelle, ce qui signifie que vous pouvez maintenant faire référence à tout chemin dans des projets comme celui - ci: /projects/project_name- en raison project_namedeC:\projects\project_name est maintenant monté.

Pour utiliser des chemins relatifs, pensez à nommer le chemin c/projectsnonprojects

4. Redémarrez tout et cela devrait maintenant fonctionner correctement. J'ai arrêté manuellement la machine virtuelle dans VirtualBox et redémarré la CLI de Docker Toolbox.

Dans mon fichier docker, je fais maintenant référence nginx.confà ceci:

volumes:
    - /projects/project_name/docker_config/nginx/nginx.conf:/etc/nginx/conf.d/default.conf

Où nginx.conf réside réellement dans C:\projects\project_name\docker_config\nginx\nginx.conf

L'explication donnée par @Ayushya était la raison pour laquelle j'ai frappé ce message d'erreur quelque peu déroutant et le ménage nécessaire peut être fait facilement comme ceci:

$ docker container prune
$ docker volume prune

J'ai eu le même problème. J'utilisais Docker Desktop avec WSL dans Windows 10 17.09.

Cause du problème:

Le problème est que Docker pour Windows s'attend à ce que vous fournissiez vos chemins de volume dans un format qui correspond à ceci:

/c/Users/username/app

MAIS, WSL utilise à la place le format:

/mnt/c/Users/username/app

C'est déroutant car lors de la vérification du fichier dans la console, je l'ai vu, et pour moi tout était correct. Je n'étais pas au courant des attentes de Docker pour Windows concernant les chemins de volume .

Solution au problème:

J'ai lié les points de montage personnalisés pour corriger les différences entre Docker pour Windows et WSL:

sudo mount --bind /mnt/c /c

Comme suggéré dans ce guide étonnant: Configurer Docker pour Windows et WSL pour fonctionner parfaitement et tout fonctionne parfaitement maintenant.

Avant de commencer à utiliser WSL, j'utilisais Git Bash et j'avais également ce problème.

J'utilise Docker ToolBox pour Windows. Par défaut, C Drive est monté automatiquement, donc pour monter les fichiers, assurez-vous que vos fichiers et dossiers sont à l'intérieur de C DRIVE .

Exemple: C:\Users\%USERNAME%\Desktop

Peut-être que quelqu'un trouve cela utile. Mon fichier de composition avait le volume suivant monté

./file:/dir/file

Comme ./file n'existait pas, il a été monté dans ABC (par défaut en tant que dossier).

Dans mon cas, j'ai eu un conteneur résultant de

docker commit ABC cool_image

Lorsque j'ai créé plus tard ./file et que docker-compose upj'ai couru , j'ai eu l'erreur:

[...] Essayez-vous de monter un répertoire sur un fichier (ou vice-versa)? Vérifiez si le chemin d'hôte spécifié existe et est du type attendu.

Le conteneur mis en place à partir de s'est cool_imagesouvenu qu'il /dir/files'agissait d'un répertoire et il était en conflit avec récemment créé et monté ./file.

La solution était:

touch ./file
docker run abc_image --name ABC -v ./file:/dir/file
# ... desired changes to ABC
docker commit ABC cool_image

Dans Windows 10, j'obtiens simplement cette erreur sans rien changer dans mon docker-compose.ymlfichier ou dans la configuration de Docker en général.

Dans mon cas, j'utilisais un VPN avec une politique de pare-feu qui bloque le port 445.

Après la déconnexion du VPN, le problème disparaît.

Je vous recommande donc de vérifier votre pare-feu et de ne pas utiliser de proxy ou de VPN lors de l'exécution de Docker Desktop.

Consultez Docker pour Windows - Règles de pare-feu pour les lecteurs partagés pour plus de détails.

J'espère que cela aidera quelqu'un d'autre.

Pourriez-vous s'il vous plaît utiliser le chemin absolu / complet au lieu de $PWD/conf/nginx.conf? Ensuite, cela fonctionnera.

EX:docker run --name nginx-container5 --rm  -v /home/sree/html/nginx.conf:/etc/nginx/nginx.conf -d -p 90:80 nginx
b9ead15988a93bf8593c013b6c27294d38a2a40f4ac75b1c1ee362de4723765b

root@sree-VirtualBox:/home/sree/html# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
b9ead15988a9        nginx               "nginx -g 'daemon of…"   7 seconds ago       Up 6 seconds        0.0.0.0:90->80/tcp   nginx-container5
e2b195a691a4        nginx               "/bin/bash"              16 minutes ago      Up 16 minutes       0.0.0.0:80->80/tcp   test-nginx

J'ai rencontré le même problème en utilisant Docker sur WSL1 sur Windows 10 avec cette ligne de commande:

echo $PWD
/mnt/d/nginx

docker run --name nginx -d \
  -v $PWD/conf/nginx.conf:/etc/nginx/nginx.conf \
nginx

Je l'ai résolu en changeant le chemin du fichier sur le système hôte en un chemin absolu de style UNIX:

docker run --name nginx -d \
  -v /d/nginx/conf/nginx.conf:/etc/nginx/nginx.conf \
nginx

ou en utilisant un chemin absolu de style Windows avec /au lieu de \comme séparateurs de chemin:

docker run --name nginx -d \
  -v D:/nginx/conf/nginx.conf:/etc/nginx/nginx.conf \
nginx

La mise à jour de Virtual Box vers la version 6.0.10 a résolu ce problème pour Docker Toolbox

https://github.com/docker/toolbox/issues/844

Je rencontrais ce genre d'erreur:

mlepisto@DESKTOP-VKJ76GO MINGW64 ~/G/Projects
$ touch resolv.conf

mlepisto@DESKTOP-VKJ76GO MINGW64 ~/G/Projects
$ docker run --rm -it -v $PWD/resolv.conf:/etc/resolv.conf ubuntu /bin/bash
C:\Program Files\Docker Toolbox\docker.exe: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:58: mounting \\\"/c/Users/mlepisto/G/Projects/resolv.conf\\\" to rootfs \\\"/mnt/sda1/var/lib/docker/overlay2/61eabcfe9ed7e4a87f40bcf93c2a7d320a5f96bf241b2cf694a064b46c11db3f/merged\\\" at \\\"/mnt/sda1/var/lib/docker/overlay2/61eabcfe9ed7e4a87f40bcf93c2a7d320a5f96bf241b2cf694a064b46c11db3f/merged/etc/resolv.conf\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

# mounting to some other file name inside the container did work just fine
mlepisto@DESKTOP-VKJ76GO MINGW64 ~/G/Projects/
$ docker run --rm -it -v $PWD/resolv.conf:/etc/resolv2.conf ubuntu /bin/bash
root@a5020b4d6cc2:/# exit
exit

Après la mise à jour de VitualBox, toutes les commandes fonctionnaient très bien 🎉

J'avais la même égratignure parce que je n'avais pas le fichier localement, donc il l'a créé en tant que dossier.

mimas@Anttis-MBP:~/random/dockerize/tube$ ls
Dockerfile
mimas@Anttis-MBP:~/random/dockerize/tube$ docker run --rm -v $(pwd)/logs.txt:/usr/app/logs.txt devopsdockeruh/first_volume_exercise
docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:58: mounting \\\"/Users/mimas/random/dockerize/tube/logs.txt\\\" to rootfs \\\"/var/lib/docker/overlay2/75891ea3688c58afb8f0fddcc977c78d0ac72334e4c88c80d7cdaa50624e688e/merged\\\" at \\\"/var/lib/docker/overlay2/75891ea3688c58afb8f0fddcc977c78d0ac72334e4c88c80d7cdaa50624e688e/merged/usr/app/logs.txt\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.
mimas@Anttis-MBP:~/random/dockerize/tube$ ls
Dockerfile  logs.txt/

unknown: essayez-vous de monter un répertoire sur un fichier (ou vice-versa)? Vérifiez si le chemin d'hôte spécifié existe et est du type attendu

J'ai eu une erreur similaire sur niginx dans l'environnement Mac. Docker n'a pas reconnu correctement le fichier default.conf. Une fois le chemin relatif du chemin absolu modifié, l'erreur a été corrigée.

      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf

Pour moi, cela n'a pas fonctionné:

volumes:
  - ./:/var/www/html
  - ./nginx.conf:/etc/nginx/conf.d/site.conf

Mais cela fonctionne bien (évidemment déplacé mon fichier de configuration dans un nouveau répertoire aussi:

volumes:
  - ./:/var/www/html
  - ./nginx/nginx.conf:/etc/nginx/conf.d/site.conf

Je vais partager mon cas ici car cela peut faire gagner beaucoup de temps à quelqu'un d'autre à l'avenir.

J'avais un docker-compose parfaitement fonctionnel sur mon macos, jusqu'à ce que je commence à utiliser docker-in-docker dans Gitlab CI. Je n'ai eu que l'autorisation de travailler en tant que maître dans un référentiel, et le Gitlab CI est auto-hébergé et configuré par quelqu'un d'autre et aucune autre information n'a été partagée, sur la façon dont il est configuré, etc.

Ce qui suit a causé le problème:

volumes:
  - ./.docker/nginx/wordpress/wordpress.conf:/etc/nginx/conf.d/default.conf

Ce n'est que lorsque j'ai remarqué que cela pouvait fonctionner sous Windows (des heures à gratter la tête), j'ai essayé de renommer le wodpress.conf en default.conf et de définir simplement les chemins du répertoire:

volumes:
  - ./.docker/nginx/wordpress:/etc/nginx/conf.d

Cela a résolu le problème!

J'ai eu ce problème sous Windows 7 car mon fichier docker se trouvait sur un lecteur différent.

Voici ce que j'ai fait pour résoudre le problème:

1. Ouvrez VirtualBox Manager
2. Sélectionnez le conteneur "par défaut" et modifiez les paramètres.
3. Sélectionnez Dossiers partagés et cliquez sur l'icône pour ajouter un nouveau dossier partagé
4. Chemin du dossier: x: \
5. Nom du dossier: / x
6. Vérifiez le montage automatique et le rendre permanent
7. Redémarrez la machine virtuelle

À ce stade, docker-compose updevrait fonctionner.

J'ai eu la même erreur sur Windows10 après une mise à jour de Docker: 2.3.0.2 (45183).

... cause \\\"not a directory\\\"\"":inconnue: essayez-vous de monter un répertoire sur un fichier (ou vice-versa)? Vérifiez si le chemin d'hôte spécifié existe et est du type attendu

J'utilisais des chemins absolus comme celui-ci //C/workspace/nginx/nginx.confet tout fonctionnait comme un charme.
La mise à jour a cassé mon docker-compose, et j'ai dû changer les chemins en /C/workspace/nginx/nginx.confavec un seul /pour la racine.

Notez que cette situation se produira également si vous essayez de monter un volume à partir de l'hôte qui n'a pas été ajouté à la section Ressources> Partage de fichiers des Préférences Docker.

L'ajout du chemin racine en tant que ressource de partage de fichiers permettra désormais à Docker d'accéder à la ressource pour la monter sur le conteneur. Notez que vous devrez peut-être effacer le contenu de votre conteneur Docker pour tenter de remonter le volume.

Par exemple, si votre application se trouve à /mysites/myapp, vous souhaiterez l'ajouter /mysitescomme emplacement des ressources de partage de fichiers.

J'ai eu le même problème, docker-compose créait un répertoire au lieu d'un fichier, puis se plantait à mi-chemin.

Ce que j'ai fait:

1. Exécutez le conteneur sans aucun mappage.

2. Copiez le .conffichier dans l'emplacement hôte:

   docker cp containername:/etc/nginx/nginx.conf ./nginx.conf

3. Retirez le conteneur ( docker-compose down).

4. Remettez le mappage.

5. Remontez le conteneur.

Docker Compose trouvera le .conffichier et le mappera , au lieu d'essayer de créer un répertoire .

J'ai résolu le problème de montage. J'utilise un environnement Win 7 et le même problème m'est arrivé.

Essayez-vous de monter un répertoire sur un fichier?

Le conteneur a un répertoire de synchronisation par défaut à C:\Users\, j'ai donc déplacé mon projet vers C:\Users\, puis recréé le projet. Maintenant ça marche.