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

Имею докер с версией 17.06.0-ce. Когда я пытаюсь установить NGINX с помощью докера с помощью команды:

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файл, все в порядке. Итак, как я могу смонтировать файл конфигурации?

Потому что докер распознает $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 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_namefrom 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/

unknown: вы пытаетесь смонтировать каталог в файл (или наоборот)? Проверьте, существует ли указанный путь к хосту и является ли он ожидаемым типом

У меня была аналогичная ошибка на 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

Я поделюсь своим случаем здесь, так как это может сэкономить много времени кому-то еще в будущем.

У меня был отлично работающий docker-compose на моих macos, пока я не начал использовать docker-in-docker в 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, потому что мой файл докеров находился на другом диске.

Вот что я сделал, чтобы исправить проблему:

1. Откройте VirtualBox Manager
2. Выберите контейнер «по умолчанию» и отредактируйте настройки.
3. Выберите Общие папки и щелкните значок, чтобы добавить новую общую папку.
4. Путь к папке: x: \
5. Имя папки: / x
6. Установите флажок Auto-mount и Make Permanent
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\, а затем воссоздал его. Теперь это работает.