Ви намагаєтесь змонтувати каталог у файл (або навпаки)?

У мене є докер з версією 17.06.0-ce. Коли я намагаюся встановити NGINX за допомогою docker з командою:

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

Це свідчить про це

docker: Відповідь помилки від демона: помилка виконання oci: container_linux.go: 262: запущений процес контейнера викликаний "process_linux.go: 339: контейнер ініціював виклик \" rootfs_linux.go: 57: монтаж \\ "/ appdata / nginx / conf / nginx.conf \\ "для кореневої файлової системи \\" / Var / Бібліотека / вантажник / AUFS / мнт / dcea22444e9ffda114593b18fc8b574adfada06947385aedc2ac09f199188fa0 \\ "в \\" / Var / Бібліотека / вантажник / AUFS / мнт / dcea22444e9ffda114593b18fc8b574adfada06947385aedc2ac09f199188fa0 / і т.д. / Nginx / nginx.conf \\ "викликав \\" не каталог \\ "\" ": Ви намагаєтесь змонтувати каталог у файл (або навпаки)? Перевірте, чи вказаний шлях хосту існує та є очікуваним типом.

Якщо не змонтувати nginx.confфайл, все в порядку. Отже, як я можу змонтувати файл конфігурації?

Оскільки Docker буде розпізнавати $PWD/conf/nginx.confяк папку, а не як файл. Перевірте , чи правильно чи $PWD/conf/містить каталог в nginx.confякості каталогу .

Тест за допомогою

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

В іншому випадку відкрийте випуск Docker .
Мені це добре працює з такою ж конфігурацією.

Це більше не повинно відбуватися (починаючи з v2.2.0.0), дивіться тут

Якщо ви використовуєте Docker для Windows , ця помилка може статися, якщо ви нещодавно змінили пароль.

Як виправити:

1. Спочатку переконайтеся, що ви видалили оновлений том розбитого контейнера
   docker rm -v <container_name>
   : Наведені нижче дії можуть працювати без необхідності попереднього видалення томів.
2. Відкрийте Налаштування Docker
3. Перейдіть на вкладку "Спільні диски"
4. Клацніть на посилання "Скинути облікові дані ..." внизу вікна
5. Повторно поділіться дисками, які ви хочете використовувати з Docker

• Вам буде запропоновано ввести своє ім’я користувача / пароль

6. Натисніть "Застосувати"
7. Перейдіть на вкладку "Скинути"
8. Натисніть "Перезапустити Docker"
9. Повторно створіть свої контейнери / томи

За вирішення проблеми заслуговує BaranOrnarli на GitHub.

TL; DR : Видаліть томи, пов’язані з контейнером.

Знайдіть назву контейнера за допомогою, docker ps -aа потім видаліть цей контейнер за допомогою:

docker rm -v <container_name>

Проблема:

Помилка, з якою ви стикаєтесь, може статися, якщо ви раніше намагалися запустити docker runкоманду, коли файл не знаходився там, де він повинен був знаходитись у хост-каталозі.

У цьому випадку демон docker створив би каталог всередині контейнера на своєму місці, який згодом не зміг би зіставити відповідний файл, коли правильні файли будуть поміщені в хост-каталог і команда docker буде запущена знову.

Рішення:

Видаліть томи, пов’язані з контейнером. Якщо вас не турбують інші обсяги контейнерів, ви також можете використовувати:

docker volume rm $(docker volume ls -q)

Відповідь для людей, які використовують Docker Toolbox

Тут було принаймні 3 відповіді, що стосуються проблеми, але не пояснюючи її належним чином і не даючи повного рішення. Це просто проблема з монтажем папки .

Опис проблеми:

Docker Toolbox обходить вимогу Hyper-V Docker, створюючи віртуальну машину (у VirtualBox, що поставляється в комплекті). Docker встановлено та запущено всередині віртуальної машини. Для того, щоб Docker працював належним чином, він повинен мати доступ до хост-машини. Що тут цього не відбувається.

Після того, як я встановив Docker Toolbox, він створив віртуальну C:\Usersмашину VirtualBox і встановив її лише на машині, як \c\Users\. Мій проект C:\projectsтак ніде не знаходився на змонтованому томі. Коли я відправляв шлях до віртуальної машини, він не існував би, оскільки C:\projectsне змонтований. Отже, помилка вище.

Скажімо, у мене був проект, що містив мою конфігурацію ngnix C:/projects/project_name/

Виправлення:

1. Перейдіть до VirtualBox, клацніть правою кнопкою миші за замовчуванням (віртуальна машина з Docker)> Налаштування> Спільні папки

2. Клацнувши на маленьку піктограму з плюсом праворуч, додайте новий спільний доступ. Я використовував такі налаштування:

3. Вище зіставляються C:\projectsз /projects( ROOT/projects) у віртуальній машині, а це означає , що тепер ви можете посилатися на будь-який шлях в проектах , як це: /projects/project_name- тому що project_nameвід C:\projects\project_nameтепер встановлено.

Щоб використовувати відносні шляхи, будь ласка, подумайте про те, щоб c/projectsне називати шляхprojects

4. Перезапустіть все, і тепер він повинен працювати належним чином. Я вручну зупинив віртуальну машину у VirtualBox і перезапустив інтерфейс інтерфейсу Docker Toolbox.

У моєму докер-файлі я зараз посилаюся приблизно nginx.confтак:

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

Де фактично проживає nginx.conf C:\projects\project_name\docker_config\nginx\nginx.conf

Пояснення, надане @Ayushya, стало причиною того, що я натиснув це дещо заплутане повідомлення про помилку, і необхідне ведення домашнього господарства можна зробити так:

$ docker container prune
$ docker volume prune

У мене була та сама проблема. Я використовував Docker Desktop з WSL у Windows 10 17.09.

Причина проблеми:

Проблема полягає в тому, що Docker для Windows очікує, що ви надасте свої шляхи тому у форматі, який відповідає цьому:

/c/Users/username/app

АЛЕ, натомість WSL використовує формат:

/mnt/c/Users/username/app

Це бентежить, тому що при перевірці файлу в консолі я його побачив, і для мене все було правильно. Я не знав про очікування Docker для Windows щодо шляхів обсягу .

Рішення проблеми:

Я зв’язав власні точки монтування, щоб виправити відмінності Docker для Windows та WSL:

sudo mount --bind /mnt/c /c

Як пропонується у цьому дивовижному посібнику: Налаштування Docker для Windows та WSL працює бездоганно, і зараз все працює ідеально.

До того, як я почав використовувати WSL, я використовував Git Bash, і у мене також була ця проблема.

Я використовую Docker ToolBox для Windows. За замовчуванням диск C монтується автоматично, тому, щоб змонтувати файли, переконайтеся, що ваші файли та папки знаходяться всередині C DRIVE .

Приклад: C:\Users\%USERNAME%\Desktop

Можливо, хтось вважає це корисним. У моєму файлі складання було встановлено наступний том

./file:/dir/file

Оскільки ./file не існувало, його було змонтовано в ABC (за замовчуванням як папку).

У моєму випадку у мене був контейнер, отриманий з

docker commit ABC cool_image

Коли я пізніше створив ./file і запустив docker-compose up, у мене сталася помилка:

[...] Ви намагаєтесь змонтувати каталог у файл (або навпаки)? Перевірте, чи вказаний шлях хосту існує та є очікуваним типом.

Контейнер, створений з cool_imageпам’яті, що /dir/fileце каталог, і він конфліктував із нещодавно створеним та змонтованим ./file.

Рішенням було:

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

У Windows 10 я просто отримую цю помилку, не змінюючи нічого у своєму docker-compose.ymlфайлі чи конфігурації Docker загалом.

У моєму випадку я використовував VPN із політикою брандмауера, яка блокує порт 445.

Після відключення від VPN проблема зникає.

Тому я рекомендую перевірити свій брандмауер і не використовувати проксі чи VPN під час запуску Docker Desktop.

Щоб дізнатися більше, перевірте Docker для Windows - правила брандмауера для спільних дисків .

Сподіваюся, це допоможе комусь іншому.

Не могли б ви використати абсолютний / повний шлях замість $PWD/conf/nginx.conf? Тоді це спрацює.

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

У мене виникла та сама проблема, використовуючи Docker через WSL1 у Windows 10 за допомогою цього командного рядка:

echo $PWD
/mnt/d/nginx

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

Я вирішив це, змінивши шлях до файлу в хост-системі на абсолютний шлях у стилі UNIX:

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

або використовуючи абсолютний шлях у стилі Windows із /замість \розділювачів шляху:

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

Оновлення Virtual Box до 6.0.10 виправило цю проблему для Docker Toolbox

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

У мене сталася така помилка:

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

Після оновлення VitualBox усі команди працювали нормально 🎉

Я мав ту саму подряпину на голові, оскільки у мене не було файлу локально, тому він створив його як папку.

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/

невідомо: Ви намагаєтесь змонтувати каталог у файл (або навпаки)? Перевірте, чи вказаний шлях хосту існує та є очікуваним типом

У мене була подібна помилка на niginx в середовищі Mac. Docker неправильно розпізнав файл default.conf. Після зміни відносного шляху на абсолютний шлях помилка була виправлена.

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

Для мене це не спрацювало:

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

Але це працює нормально (очевидно, мій конфігураційний файл також переміщений у новий каталог:

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

Тут я поділюсь своєю справою, оскільки це може заощадити багато часу для когось іншого в майбутньому.

У мене був ідеально працюючий докер-компонент на моїх макосах, поки я не почав використовувати докер-докер у Gitlab CI. Мені дали лише дозволи працювати Майстром у сховищі, а Gitlab CI самостійно розміщується та налаштовується кимось іншим, і жодної іншої інформації про те, як це налаштовано, тощо не передається

Проблему спричинило таке:

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

Лише коли я помітив, що це, можливо, працює під вікнами (години дряпали голову), я спробував перейменувати wodpress.conf у default.conf і просто встановив імена директорій:

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

Це вирішило проблему!

У мене була ця проблема під Windows 7, оскільки мій файл docker знаходився на іншому диску.

Ось що я зробив, щоб вирішити проблему:

1. Відкрийте VirtualBox Manager
2. Виберіть контейнер "за замовчуванням" та відредагуйте налаштування.
3. Виберіть Спільні папки та клацніть піктограму, щоб додати нову спільну папку
4. Шлях до папки: x: \
5. Назва папки: / x
6. Позначте пункт Автоматичне монтування та Зробити постійним
7. Перезапустіть віртуальну машину

На цей момент docker-compose upмає запрацювати.

Я отримав ту саму помилку в Windows10 після оновлення Docker: 2.3.0.2 (45183).

... причиною \\\"not a directory\\\"\"":невідомо: Ви намагаєтесь змонтувати каталог у файл (або навпаки)? Перевірте, чи вказаний шлях хосту існує та є очікуваним типом

Я використовував абсолютні шляхи, як цей, //C/workspace/nginx/nginx.confі все працювало як шарм.
Оновлення зламало мою докер-композицію, і мені довелося змінити шляхи на /C/workspace/nginx/nginx.confодин /для кореневої.

Зауважте, що така ситуація також трапиться, якщо ви спробуєте підключити том із хосту, який не був доданий до розділу Ресурси> Спільний доступ до файлів у Налаштуваннях Docker.

Додавання кореневого шляху як ресурсу спільного використання файлів тепер дозволить Docker отримати доступ до ресурсу, щоб підключити його до контейнера. Зверніть увагу, що, можливо, вам доведеться стерти вміст контейнера Docker, щоб спробувати повторно встановити том.

Наприклад, якщо ваша програма розташована за адресою /mysites/myapp, ви захочете додати /mysitesяк ресурс спільного доступу до файлів розташування.

У мене була та ж проблема, docker-compose створював каталог замість файлу, а потім аварійно завершував роботу.

Що я зробив:

1. Запустіть контейнер без відображення.

2. Скопіюйте .confфайл у розташування хосту:

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

3. Вийміть контейнер ( docker-compose down).

4. Покладіть назад відображення.

5. Повторно встановіть контейнер.

Docker Compose знайде .confфайл і зіставить його, замість того, щоб намагатися створити каталог .

Я вирішив проблему монтування. Я використовую середовище Win 7, і та сама проблема трапилася і зі мною.

Ви намагаєтесь змонтувати каталог у файл?

У контейнері за замовчуванням є каталог синхронізації C:\Users\, тому я перемістив свій проект у C:\Users\, а потім відтворив проект. Зараз це працює.