Да, это возвращает меня обратно!

Работает ли после fig kill и fig rm ? У меня есть подозрение, что это ошибка Docker с VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

Работает ли после fig kill и fig rm ? У меня есть подозрение, что это ошибка Docker с VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

нет, не совсем,

Такая же ошибка здесь при попытке использовать тома с файлом ...

Здесь не работает на VFS:

Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
Execution Driver: native-0.2
Kernel Version: 3.10.42-xenU-12-e888729-x86_64
Operating System: Ubuntu 14.04 LTS

Но работает отлично работает на моем персональном компьютере:

$ docker info
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
Execution Driver: native-0.2
Kernel Version: 3.13.0-35-generic
Operating System: Ubuntu 14.04.1 LTS

Что касается записей, вывод версии докера такой же, но я уверен, что это не так важно, поскольку, насколько я помню, он отлично работал и в 1.2 ...

Client version: 1.3.0
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): c78088f
OS/Arch (client): linux/amd64
Server version: 1.3.0
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): c78088f

Итак, единственная разница, которую я могу заметить, - это версия ядра. Первый (который не работает) - это VFS, второй - мой компьютер. Это помогает понять, что происходит?

Хммм, извините за загрязнение. Простая опечатка. Не похоже, что я первый, кого это поймает.

Если "-v" вызывается из несуществующего местоположения на стороне хоста (из-за опечатки), он создает пустой каталог и все родительские каталоги, если это необходимо. Затем, когда он пытается смонтировать этот пустой каталог в контейнере и что файл уже находится в целевом местоположении, он выдает это сообщение.

Я не думаю, что докеру должно быть разрешено создавать каталоги на стороне хоста. Следует ли мне удалить свой предыдущий комментарий (и этот?), Чтобы не загрязнять эту ветку?

Я добавлю свои два цента / подниму эту тему. Было бы очень полезно иметь возможность добавлять отдельные файлы в docker-compose . Прямо сейчас у меня должен быть отдельный каталог для каждого из моих контейнеров, но в большинстве из них есть только 1 или 2 файла. Было бы здорово поместить их все в одну папку, а затем просто ссылаться на них по отдельности.

Я думаю, что в какой-то момент была ошибка при создании томов, из которых были включены файлы, подключенные к привязке.
Я не думаю, что сегодня это проблема.

Кажется, это повторяющаяся проблема.

Согласно справке @ md5 и другим комментариям, я могу точно воспроизвести это поведение при следующих условиях:

• CentOS 7
• Docker 1.5.0 (пакет yum docker-1.5.0-28.el7.centos)
• докер-составить 1.1.0

Такого поведения не было в пакете yum docker-1.5.0-1.el7 .

Пример:

Используя простую декларацию услуги:

test:
  image: nginx
  ports:
    - "80:80"
  volumes:
    - sites/test.conf:/etc/nginx/conf.d/default.conf

При попытке связать монтировать файл, а не каталог, docker-compose производит следующее:

docker create_container <- (name=u'webcluster_test_1', image=u'nginx:latest', environment={}, volumes={u'/etc/nginx/conf.d/default.conf': {}}, detach=True, ports=[u'80'])
file exists at %!s(MISSING), can't create volume there

Тем не менее, эквивалентная команда docker run будет успешной:

docker run --name test -d -p "80:80" \
  -v ${PWD}/sites/test.conf:/etc/nginx/conf.d/default.conf \
  nginx

@dayglojesus Похоже, вы используете версию Docker для разработки.
Можете ли вы предоставить результат docker version ?
Сообщение об ошибке, которое у вас есть, взято из этого коммита: https://github.com/docker/docker/commit/b0ed2da4418d62d2d7b940b49e0e89bdcd264569

Этого коммита нет в выпущенной версии Docker, есть исправление в master, и он является частью серии 1.6 RC.

@ cpuguy83 Сообщает, что это версия 1.5.0, а не 1.6 RC:

Docker version 1.5.0-dev, build fc0329b/1.5.0

Это «официальная» сборка, доступная в репозиториях CentOS 7 yum, никаких настроек для репозиториев разработчиков.

Почему docker-compose демонстрирует такое поведение, а docker run - нет? Это ошибка в Docker или docker-compose ?

Дайте мне знать, если вам понадобится дополнительная информация.

@dayglojesus Да, это не выпущенная версия docker. 1.5.0-dev была создана после того, как docker 1.5.0 был вырезан.
Ошибка отсутствует в выпущенной версии докера.

@ cpuguy83 Понятно . Странно, интересно, как этот пакет попал в репо? Вы случайно не знаете, какой пакет yum соответствует актуальному выпуску Docker 1.5.0 для CentOS 7?

Я не уверен ... пинг @ lsm5

@dayglojesus, поэтому вы установили докер, перекомпилированный RHEL, который имеет несколько патчей redhat поверх докера восходящего потока. Если это то, что вас не волнует, и вам нужен только rpm с восходящим докером, см. Http://wiki.centos.org/Cloud/Docker . Здесь упоминается дополнительное репо, которое содержит rpm, который я создаю отдельно как часть CentOS virt SIG.

Если вам действительно небезразлична вся эта информация о rhel, сообщите об ошибке на https://bugzilla.redhat.com . HTH

Подал заявку RHEL по этой проблеме. https://bugzilla.redhat.com/show_bug.cgi?id=1209625
Спасибо, @ lsm5.

Ммм, получилось то же самое на ubuntu 14.04lts с докером 1.5

происходит со мной на linux mint / ubuntu, файлы вообще не монтируются (они должны перезаписывать контейнер, но они этого не делают)

У меня такая же проблема с etc-localtime на

• Linux guest.vm 3.13.0-49-generic # 81-Ubuntu
• x86_64 x86_64 x86_64 GNU / Linux
• Описание: Ubuntu 14.04.2 LTS
• Релиз: 14.04
• Кодовое имя: надежный
• докер версия 1.5

Если у вас возникла проблема, +1 не помогут, тем более что они, скорее всего, вообще не связаны с проблемой OP.

Укажите, какую докерную команду вы используете, что вы ожидаете увидеть и что на самом деле видите.
Также включите вывод docker info и docker version .
Благодарю.

@ cpuguy83 хорошо, вот о моем случае:

команда:

docker run -d --name webserver -p 80:80 -v ~/www/:/home/site/www/ -v ~/docker/share/apache_logs/:/home/site/logs -v ~/.gitconfig:/home/site/.gitconfig ...

ситуация: ~ / .gitconfig отсутствует на хосте перед выполнением этой команды

что происходит: ~ / .gitconfig создается как каталог, принадлежащий пользователю root (вместо текущего пользователя), и контейнер не запускается, останавливаясь с сообщением о невозможности смонтировать ~ / .gitconfig (используя полный путь в его текст, а не сокращение тильды)

что я ожидаю увидеть: либо докер должен создать ~ / .gitconfig как пустой файл, принадлежащий текущему пользователю, и успешно запустить контейнер, либо отказаться от запуска с лучшим сообщением об ошибке и вообще не создав ~ / .gitconfig

информация о докере:

user<strong i="14">@ubuntu14server</strong>:~$ docker info
Containers: 5
Images: 153
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 163
Execution Driver: native-0.2
Kernel Version: 3.16.0-30-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 1
Total Memory: 3.847 GiB
Name: ubuntu14server
ID: D52N:QLNG:UE33:N7F3:LZJP:NCF4:6OUS:COOJ:ISL3:2CRK:ZX3U:L3DW
WARNING: No swap limit support
user<strong i="15">@ubuntu14server</strong>:~$ docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.4.1
Git commit (client): a8a31ef
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.4.1
Git commit (server): a8a31ef

@gggeek Проблема здесь в том, что мы не можем определить, что вам нужен файл (это уже обсуждалось ранее).
В вашем стартовом скрипте я бы рекомендовал добавить touch ~/.gitconfig перед вашей командой docker run .

:-D вот чем я закончил.
А как насчет того, чтобы выбрать маршрут 2 и не создавать папку?

@gggeek Этот корабль уже отплыл, и, к сожалению, это

;-( Ну что ж

У меня эта ошибка с Docker version 1.6.0, build 4749651

Связанная проблема: https://github.com/docker/docker-py/issues/546

Я думаю, что нашел одну вещь, связанную с решением этой проблемы. Я использую последнюю версию docker-compose (1.20) / docker (1.6.0) на AWS. И получал эту ошибку каждый раз, когда пытался запустить nginx:

Cannot start container e9586e9e936c9b3991283c676bd071abb92a7b6b3bc0b667cf77a68fa4cc9222: [8] System error: mounting into / is prohibited

В отчаянии я заглянул в nginx Dockerfile и увидел, что он открывает один том. Итак, я добавил этот том в список, который я смонтировал, и вдруг все заработало!

Таким образом, разница между стыками docker-compose и docker определяется значением по умолчанию для томов.

Проблема закрыта, но как ее решить?
У нас та же проблема, что мы не можем смонтировать файлы в контейнер докеров.
Последняя версия Docker Toolbox (docker 1.9) для Windows
Запуск контейнера заканчивается в

Cannot start container XXX: [8] System error: not a directory

То же, что и Саша-Эгерия, решение?

Проблема, о которой вы сообщаете, не совпадает с этой. Эта проблема была ошибкой в ​​более ранней версии Docker, которая была исправлена ​​давно.

Возможно, ваша проблема связана с # 2268? Если бы вы могли опубликовать в этой проблеме полный вывод docker-compose version , docker info , содержимое вашего docker-compose.yml и команды, которые вы выполнили, мы могли бы продолжить отладку проблема.

Я наконец решил свою проблему, используя Git Bash и команду «docker-machine ssh [MACHINE]» для работы с Docker.
Новая оболочка Docker Quickstart Terminal (1.9d) в Windows действительно плохо работает.

У меня такая же проблема.
Docker-compose: 1.5.1
Докер: 1.9.1

nginx:
  image: nginx
  links:
   - web
  volumes:
   - .:/code
   - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf <------
  ports:
   - "80:80"

@ jordi12100 Если вы получаете каталог, значит он не может найти файл.

Воспроизведено в докере 1.9.1 при попытке монтирования с помощью server.conf:/etc/server.conf где файл /etc/server.conf существует в образе.

Использование относительного пути, кажется, заставляет докер рассматривать файл хоста как имя папки. Поскольку это файл в контейнере, и мы не можем подключить папку к существующему файлу /etc/server.conf , это не удается.

Использование абсолютного пути к server.conf решает проблему для меня docker run -v /absolute/path/to/server.conf:/etc/server.conf ... а docker обрабатывает server.conf как обычный файл.

Относительные пути должны начинаться с . , поэтому попробуйте ./server.config .

Без него он считается именованным томом.

У меня такая же проблема, и я не могу смонтировать файл даже с . . Docker (или docker-compose?) Считает файл папкой, если я не укажу абсолютный путь к файлу.

Докер: 1.9.1
Docker-compose: 1.5.2

Используйте ./server.conf:/etc/server.conf с docker-compose works. Но опция docker CLI -v жалуется на недопустимый путь, принимает только абсолютный путь к монтируемому файлу.

@kirisetsz правильно; docker-compose принимает относительные пути (которые относятся к файлу docker-compose.yml ); Compose позаботится о преобразовании относительного пути в абсолютный. При использовании докера (не компоновке) необходимо указать абсолютный путь. Вы можете использовать -v $(pwd)/server.conf:/etc/server.conf если не хотите вводить весь путь

Подтверждаю, у меня такая же проблема с:
Mac OS X.10.11.3
Docker version 1.9.1, build a34a1d5
docker-compose version 1.5.2, build 7240ff3
Даже если я укажу абсолютный или относительный путь к хосту, у меня будет тот же ответ:
ERROR: Cannot start container a9ed08a3ee639f61ff2720745011c940a5fff5b9b98bda6a45156a80381c5328: [8] System error: not a directory
К вашему сведению:

nginx:
  image: nginx
  ports:
    - 8080:80
    - 8443:443
  volumes_from:
    - application
  volumes:
    - ./SCM/Data/Etc/Configuration/nginx.conf:/etc/nginx/conf.d/default.conf:ro
    - ./LOGS/nginx:/var/log/nginx:rw
  links:
    - fpm

У меня тоже есть эта проблема

composer:
    image: php7-composer:latest
    working_dir: /data/application
    volumes:
      - ./.composer/cache:/var/composer/cache:rw
      - ./.composer/auth.json:/var/composer/auth.json:rw

В этом примере auth.json создается как каталог на хост-машине, и это должен быть файл. Если я сначала помещаю auth.json на хост-машину, он жалуется, что это не каталог.

Для меня тоже, когда я пытаюсь:

объемы:
- ./docker/default.conf:/etc/nginx/conf.d/default.conf

Я получаю сообщение об ошибке: ОШИБКА: не удается запустить контейнер 9f ...... f1e: [9] Системная ошибка: не каталог

Если я изменю conf.d на что-то еще, он будет работать, но смонтирует default.conf как каталог вместо файла

Windows 10
Версия докера: 1.10.1
docker-compose версия 1.6.0, сборка cdb920a

Можно ли повторно открыть этот баг, раз уж он был закрыт без разрешения? Это все еще происходит. Мой случай такой же, как и у многих других, я пытаюсь смонтировать файл nginx.conf в образ nginx в /etc/nginx/nginx.conf.

В docker-compose.yml:

nginx:
  image: "nginx:1.9.7"
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - "./config/nginx.conf:/etc/nginx/nginx.conf:ro"
    - "./config/development-cert.pem:/etc/nginx/cert.pem:ro"
    - "./config/development-key.pem:/etc/nginx/key.pem:ro"

Вывод:

$ docker-compose up -d nginx
Starting example_nginx_1
ERROR: Cannot start container 81f4237f3f0e962d8861ca30744bfd78c3b61b4ea5891a19c712c682ecc5142c: [9] System error: not a directory

Я запускаю Docker в OS X (10.11.3), используя виртуальную машину Vagrant с плагином VMware Fusion (VMware Fusion 8.1.0) и хостом CoreOS. Соответствующая информация о версии:

$ vagrant -v
Vagrant 1.8.1

$ vagrant plugin list
vagrant-vmware-fusion (4.0.8)

$ docker-compose -v
docker-compose version 1.6.0, build unknown

$ docker info
Containers: 6
 Running: 5
 Paused: 0
 Stopped: 1
Images: 6
Server Version: 1.10.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.4.1-coreos
Operating System: CoreOS 970.1.0 (Coeur Rouge)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 2.391 GiB
Name: localhost
ID: 73NW:JIK2:PTGX:3JVG:JZM4:NON4:DXOD:NAUU:UN7Q:T3F5:ZMZG:UWGR
Username: redacted
Registry: https://index.docker.io/v1/

$ docker version
Client:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   9e83765
 Built:        Fri Feb 12 22:11:40 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.4.3
 Git commit:   88b8b3a
 Built:
 OS/Arch:      linux/amd64

Пожалуйста, посмотрите мой комментарий здесь: https://github.com/docker/compose/issues/424#issuecomment -157751229

Ошибка может выглядеть так же, но, скорее всего, вызвана другой проблемой.

Также см. Https://github.com/docker/docker/issues/13670 и https://github.com/docker/docker/issues/19304.

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

Попробуйте использовать https://github.com/brikis98/docker-osx-dev

Я столкнулся с этой проблемой и, вытащив все волосы, обнаружил, что папка была символической ссылкой на корневую папку.

Все содержимое перемещено в (мою) папку, принадлежащую пользователю, и работает нормально.

Докер-1.12.0-rc2
Докер-машина 0.8.0-rc1
Докер-составить 1.8.0-rc1

Нашел эту ветку через гугл. У меня тоже есть эта проблема. Я не могу привязаться к отдельным файлам, OSX.

Docker version 1.12.0-rc4, build e4a0dbc, experimental
docker-compose version 1.8.0-rc2, build c72c966

Докер был обновлен сегодня.

Обновление: снимок экрана, показывающий, что он пытается смонтировать как каталог, а не файл.

У меня такая же проблема :-( не могу смонтировать один файл

Client:
 Version:      1.12.0-rc4
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   e4a0dbc
 Built:        Wed Jul 13 03:28:51 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc4
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   e4a0dbc
 Built:        Wed Jul 13 03:28:51 2016
 OS/Arch:      linux/amd64
 Experimental: true

также подтверждая проблему

В сегодняшнем обновлении OSX это исправлено. Мне удалось смонтировать один файл с помощью docker-compose.

Docker version 1.12.0, build 8eab29e, experimental
docker-compose version 1.8.0, build f3628c7

Пытался смонтировать файл с помощью docker-compose

// docker-compose.yml
version: '2'
services:
  web:
    build: .
    privileged: true
    volumes:
      - "/usr/src/app/app.conf:/etc/app.conf"
    entrypoint: /run.sh

На хост-машине

ls /usr/src/app/ -la
total 12
drwxr-xr-x   3 root root 4096 Aug  9 11:08 .
drwxr-xr-x 101 root root 4096 Aug  8 14:16 ..
drwxr-xr-x   2 root root 4096 Aug  9 11:08 app.conf

Docker-compose создал каталог: drwxr-xr-x app.conf
вместо файла.

Это нормальное поведение? Я предполагал, что файл будет создан и смонтирован.

Буду очень признателен, если кто-нибудь даст мне разъяснения.

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Docker version 1.12.0, build 8eab29e
docker-compose version 1.8.0, build f3628c7

@bogulean, если файл или каталог, который вы пытаетесь связать-монтировать, не существует, докер не может определить, ожидаете ли вы _file_ или _directory_ в этом случае (если /usr/src/app/app.conf не Существуют), демон docker создает каталог в этом месте и монтирует его в контейнере.

Обратите внимание, что мы пытались не рекомендовать / удалить автоматическое создание пути (и вместо этого выдать ошибку), но это было слишком много обратного несовместимого изменения (некоторые люди полагаются на это поведение), поэтому нам пришлось сохранить это поведение.

@thaJeztah Спасибо за быстрый ответ!
Я попытался создать файл "/usr/src/app/app.conf" вручную перед запуском docker-compose, и результат ниже:

ERROR: for web  Cannot start service web: oci runtime error: rootfs_linux.go:53: mounting "/var/lib/docker/aufs/mnt/dc65b60b56bae344412f8c23a35f6a19d897b0cad0673bcb9316267ed02a44fe/etc/app.conf" to rootfs "/var/lib/docker/aufs/mnt/dc65b60b56bae344412f8c23a35f6a19d897b0cad0673bcb9316267ed02a44fe" caused "not a directory"
ERROR: Encountered errors while bringing up the project.

@bogulean, каковы ваши настройки? И демон, и клиент работают на одном компьютере, или вы работаете с удаленным демоном (или демоном, работающим на виртуальной машине?)

@thaJeztah Я использую хост DO, Ubuntu 16.04 LTS,
docker-compose и docker, установленные на нем, вы можете найти версии ниже:

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Docker version 1.12.0, build 8eab29e
docker-compose version 1.8.0, build f3628c7

все работает на этой машине туда я подключаюсь по ssh

Пытаясь исключить docker compose из уравнения, можете ли вы попытаться воспроизвести с помощью;

docker run --rm -v /usr/src/app/app.conf:/test/app.conf alpine cat /test/app.conf

который должен связать-смонтировать файл конфигурации и распечатать его содержимое

docker run -it --rm -v /usr/src/app/app.conf:/test/app.conf alpine sh -c 'cat /test/app.conf'
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
e110a4a17941: Pull complete
Digest: sha256:3dcdb92d7432d56604d4545cbd324b14e647b313626d99b889d0626de158f73a
Status: Downloaded newer image for alpine:latest
Hello from /usr/src/app/app.conf

@thaJeztah Я мог бы также запустить docker-compose.yml, если вы дадите его мне для тестирования

@bogulean правильно, похоже, проблема с docker-compose или с изображением, которое вы создаете / запускаете. Это было бы эквивалентом предыдущего теста, но затем через docker-compose;

version: '2'
services:
  web:
    image: "alpine:latest"
    volumes:
      - "/usr/src/app/app.conf:/test/app.conf"
    command: "cat /test/app.conf"

И попробовать, работает ли оно;

docker-compose run web

(который также должен напечатать Hello from /usr/src/app/app.conf )

@thaJeztah , большое спасибо! Ваш docker-compose.yml вернул Hello from /usr/src/app/app.conf
Это заставило меня понять, что я делаю что-то не так в другом месте, и я обнаружил, что в моем Dockerfile есть строка:
VOLUME ["/usr/src/app.conf"]
удалил его, и файл начал связываться, как ожидалось.

Спасибо за ваше время.

Рад слышать и рад помочь!

Проблема в вашем случае заключается в том, что VOLUME также ожидает каталог, поэтому создал том и попытался смонтировать его в /usr/src/app.conf . Лучшим способом работы с отдельными файлами с хоста обычно является учет этой ситуации, например, наличие каталога /usr/src/config/ ; затем вы должны привязать-монтировать (или использовать том) для этого каталога вместо файла. Очевидно, не всегда возможно

@thaJeztah , у меня такая же проблема при запуске:

docker run -v $(pwd)/filebeat.yml:/filebeat.yml prima/filebeat:1.2 cat filebeat.yml
cat: filebeat.yml: Is a directory

/ определенно существует в изображении / контейнере:

docker run -v $(pwd)/filebeat.yml:/filebeat.yml prima/filebeat:1.2 ls -al
drwxr-xr-x   2 root root   40 Aug  9 20:46 filebeat.yml

Кажется, это ошибка Docker в целом, не связанная с Docker Compose.
Не знаю, зачем Docker в этом случае создать каталог.

Есть идеи? Большое спасибо!

Я также пробовал ваш пример с альпийским изображением. Одна и та же. cat: read error: Is a directory

@thasmo Вы получаете эту ошибку, потому что filebeat.yml - это каталог, а не файл.
Вы должны убедиться, что файл существует на хосте, прежде чем пытаться смонтировать его в контейнер, иначе docker создаст для вас каталог.

@ cpuguy83 , кажется, я только что нашел проблему. Я использую Docker в Windows через Docker Machine и VirtualBox, и он, вероятно, не может смонтировать локальный файл через VirtualBox в контейнер.
https://docs.docker.com/docker-for-windows/troubleshoot/#/host -filesystem-sharing

Я обнаружил эту проблему в докере для чистой установки в юбилейном обновлении Windows 10.
На самом деле эта проблема очень простое решение

Требуется общий доступ к дискам в параметрах докеров http://www.awesomescreenshot.com/image/1510321/0f1a81d7a8883df5a61bcdf04b3994cf
Смотрит находит и решает проблему.

По-прежнему проблема в ubuntu 16.10

➜  gi_proxy git:(master) ✗ docker -v
Docker version 1.12.3, build 6b644ec

docker run --name hap ... -v /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf:/etc/resolv.conf

docker: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:359: container init caused \\\"rootfs_linux.go:53: mounting \\\\\\\"/home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf\\\\\\\" to rootfs \\\\\\\"/mnt/sda1/var/lib/docker/aufs/mnt/34ee49dcff906310df08b5a0bdf02ebafd302c1c7bf8b81ecd2778757fdb5713\\\\\\\" at \\\\\\\"/mnt/sda1/var/lib/docker/aufs/mnt/34ee49dcff906310df08b5a0bdf02ebafd302c1c7bf8b81ecd2778757fdb5713/etc/resolv.conf\\\\\\\" caused \\\\\\\"not a directory\\\\\\\"\\\"\"\n".

Если я изменил запуск докера для монтирования в файл, которого не существует, например / tmp / foo, он работает, но монтирует каталог.

@djpate - это ваш демон докера, работающий на том же хосте (а не на виртуальной машине?). Если /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf не существует на машине, на которой запущен демон docker, тогда демон создаст _directory_ с этим именем и попытается связать-смонтировать его в /etc/resolv.conf внутри контейнера. Поскольку /etc/resolv.conf - это _file_, монтирование каталога поверх файла не удастся.

Сказав это, я настоятельно не рекомендую заменять /etc/resolv.conf локальным файлом; /etc/resolv.conf управляется докером, чтобы установить правильный DNS-сервер для использования. Docker имеет встроенный DNS-сервер для обнаружения служб, поэтому переопределение этого файла приведет к тому, что обнаружение служб не будет работать.

Если вы хотите установить параметры DNS, используйте параметры --dns , --dns-opt и --dns-search для docker run ;

--dns value                   Set custom DNS servers (default [])
--dns-opt value               Set DNS options (default [])
--dns-search value            Set custom DNS search domains (default [])

Это установит эти параметры, не вызывая неожиданных результатов. Обратите внимание, что DNS внутри контейнера всегда будет 127.0.0.11 (встроенный DNS-сервер), но этот сервер автоматически перенаправляет запросы на DNS-сервер, указанный вами с помощью --dns

@thaJeztah Я новичок в докере, но думаю, что он работает на моей машине. Я в основном установил docker-engine и docker-machine на обычную локальную машину ubuntu. Это среда разработки моей компании, которая, похоже, работает для всех на докере для Mac.

Я заменю его на параметр DNS, как вы упомянули, я не знал об этом. Спасибо! Но я думаю, что ошибка все еще существует.

Это не работает для меня ни на docker-compose v1.6.2, ни на docker v1.10.2 :(

Использование абсолютных путей работает, но, к сожалению, для моего варианта использования абсолютные пути абсолютно не работают :(. Я пробовал все комбинации ./ и ../ которые только могу придумать.

РЕДАКТИРОВАТЬ: Также я работаю в Linux без виртуальных машин, поэтому решение @thaJeztah для меня не работает

ОС - Ubuntu 14.04

Докер сейчас обновлен до 1.13.1. Пожалуйста, обновите свой Docker. Работает, с 1.12.х.

Ах, спасибо. Обновит докер и обновит, если / когда исправят :)

РЕДАКТИРОВАТЬ: Сработало! Спасибо @guice

@thaJeztah

Если файл или каталог, который вы пытаетесь связать-монтировать, не существует, docker не может определить, ожидаете ли вы файл или каталог, в этом случае (если /usr/src/app/app.conf не не существует), демон docker создает каталог в этом месте и монтирует его в контейнере.
Обратите внимание, что мы пытались не рекомендовать / удалить автоматическое создание пути (и вместо этого выдать ошибку), но это было слишком много обратного несовместимого изменения (некоторые люди полагаются на это поведение), поэтому нам пришлось сохранить это поведение.

Я очень расстроен после шести часов использования именно этого варианта использования и теперь обнаружил, что это невозможно.
Почему бы не добавить в объявление тома что-то вроде «флага файла», учитывая, что мы можем указать дополнительные параметры монтирования, такие как :ro и :rw ?

volumes:
  - "./config.json:/app/config.json:rwf"

Когда я сопоставляю файл контейнера с файлом хоста, я ожидаю, что файл хоста будет создан (скопирован из контейнера) при инициализации контейнера.
К сожалению, довольно часто можно найти контейнеры, файлы конфигурации которых помещены непосредственно в корневой каталог приложения, и, очевидно, вы не хотите «увеличивать объем» всего корня. В таком случае было бы особенно полезно, если бы это работало.

@malyzeli , возможно, вы захотите взглянуть на секреты как на способ внедрения такой конфигурации или создания шаблонов при запуске.
Тома действительно предназначены для настойчивости, а не для конфигурации.
На самом деле докер вообще не должен автоматически создавать пути к хостам, и это поведение было удалено в новых API.

@ cpuguy83

Я не понимаю вашей точки зрения, поэтому, пожалуйста, объясните или исправьте мои предположения, потому что я новичок в экосистеме Docker.

Возможно, вы захотите взглянуть на секреты как на способ внедрения такой конфигурации или создания шаблонов при запуске.

Что делать, если я не знаю, как будет выглядеть файл конфигурации, потому что он создается каким-то мастером установки непосредственно из приложения (и который в конечном итоге изменяется от версии к версии)?
Многие приложения имеют такую ​​первоначальную настройку, например Limesurvey и NodeBB.

Тома действительно предназначены для настойчивости, а не для конфигурации.

Вы подразумеваете, что конфигурация существующего контейнера не должна быть постоянной?
Тогда что, если я захочу создать резервную копию какой-то части моей многоконтейнерной инфраструктуры?
Я хочу, чтобы данные и конфигурация были в томах, чтобы я мог быстро восстановить их, если что-то случится.

На самом деле докер вообще не должен автоматически создавать пути к хостам, и это поведение было удалено в новых API.

На самом деле мне это не нужно для создания путей к хостам, а для инициализации данного тома с существующими данными изображения (например, «экстернализировать» некоторые шаблоны html, которые я хочу иметь редактируемые из хост-системы и / или другого контейнера), и он все еще работает точно так, как указано в ссылке на

Команда docker run инициализирует вновь созданный том любыми данными, которые существуют в указанном месте в базовом образе.

Что делать, если я не знаю, как будет выглядеть файл конфигурации, потому что он создается каким-то мастером установки непосредственно из приложения (и который в конечном итоге изменяется от версии к версии)?

Дайте ему создать, извлеките его из образа / контейнера, сделайте из него секрет

Я хочу, чтобы данные и конфигурация были в томах, чтобы я мог быстро восстановить их, если что-то случится.

Используйте секреты. Мы также рассматриваем специальный объект config который похож на секреты, но не настолько ограничен ... но сегодня секреты - это то, что доступно.

На самом деле мне это не нужно для создания путей к хостам, а для инициализации данного тома с существующими данными изображения (например, «экстернализировать» некоторые шаблоны html, которые я хочу иметь редактируемые из хост-системы и / или другого контейнера), и он все еще работает точно так, как указано в ссылке на Dockerfile:

Крепления для привязки - это не тома. Ссылка на Dockerfile говорит о томах. К сожалению, для обоих используется docker run -v .

Я определенно не говорю, чтобы не использовать тома для хранения конфигурации, я говорю, что вы должны оценить, есть ли лучшее решение (и секреты IMO для этого намного лучше).

Связывание хоста - плохое решение для чего-либо, кроме взятия того, что уже существует на хосте, и помещения его в контейнер ... и даже в этом случае обычно не работает, когда вы говорите о кластерных средах.

@ cpuguy83

Дайте ему создать, извлеките его из образа / контейнера, сделайте из него секрет

Да, это то, что я делаю, но все равно это кажется досадно сложным .. :-)

Используйте секреты. Мы также рассматриваем специальный объект config который похож на секреты, но не настолько ограничен ... но сегодня секреты - это то, что доступно.

Я разберусь, секретов не знал, спасибо!

Крепления для привязки - это не тома. Ссылка на Dockerfile говорит о томах. К сожалению, для обоих используется docker run -v .

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

Для тех, кто видит эту ошибку в Windows ... даже если у вас есть общие диски ...

Возникла проблема, при которой, если вы используете Docker Windows (с docker-compose) и используете определенные учетные данные для «Совместного использования диска», такие как C: \ или D: \ и т. Д., Вам может потребоваться отменить общий доступ, снова предоставить общий доступ к диску, повторно ввести учетные данные, иначе вы получите сообщение об ошибке, например:

"ОШИБКА: для ... Невозможно запустить службу yourservice: oci runtime error: container_linux.go: 262: запуск процесса контейнера вызвал" process_linux.go: 339: container "вызвал \" rootfs_linux.go: 57: mount \

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

БаранОрнарли, как быть тем, у кого стоит DockerToolbox?

Здесь та же проблема, что и у большинства людей здесь. Но я снова заработал, просто перезапустив виртуальную машину.

Windows 10 для образовательных учреждений
Панель инструментов Docker, 17.10.0-ce
VirtualBox 5.2.2

Запуск этого через docker CLI работает:
docker run -d -p 8080:80 -v $(pwd)/src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf учебник / nginx

Запуск того же через docker-compose, не сделал:
отрезать
volumes: - ./src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf
То есть, пока я не выключу виртуальную машину через графический интерфейс VirtualBox и снова не запустил терминал быстрого запуска Docker.

С тех пор многократное уничтожение контейнеров и сборка докеров больше не возвращали ошибку.

Надеюсь, это кому-то поможет.

У меня та же проблема. А пока я использую папку докеров реальных томов в docker-compose.yml. Это /var/lib/docker/volumes..../file.ext в качестве временного решения
(Докер версии 17.12.0-ce, сборка c97c6d6)

Если у вас есть такая проблема, также проверьте, поделились ли вы своим каталогом в Windows.

Я использую Ubuntu 14.04. Когда я запускаю команду docker-compose up -d , возникает следующая ошибка:

ERROR: for frontend Cannot start service frontend: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused \"rootfs_linux.go:58: mounting \\\"/home/curso-docker/email-worker-compose/nginx/default.conf\\\" to rootfs \\\"/var/lib/docker/aufs/mnt/ffc214cd493c376554125473ba95e8cd918cd3ad73b6aa8292f51ce84beca8a6\\\" at \\\"/var/lib/docker/aufs/mnt/ffc214cd493c376554125473ba95e8cd918cd3ad73b6aa8292f51ce84beca8a6/etc/nginx/conf.d/default.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

Я использую абсолютный путь для сопоставления тома /home/curso-docker/email-worker-compose/nginx/default.conf с моего хоста.

У кого-нибудь есть представление об этой проблеме?

@AzeredoGabriel для меня то, что @BaranOrnarli упомянул ранее, работало как шарм. Сбросьте учетные данные для общего диска, поделитесь им снова, и он должен работать. Не знаю, почему он внезапно перестал работать, но теперь это снова.

есть новости по этому поводу? По-прежнему кажется невозможным смонтировать один файл

@Karlheinzniebuhr Это никогда не было проблемой. Docker позволяет монтировать файлы в контейнер, но вы не можете монтировать файл в каталог или наоборот.

есть новости по этому поводу? По-прежнему кажется невозможным смонтировать один файл

попробуйте сопоставить файл с существующим каталогом. Docker всегда пытается создать каталог, если он не существует.

@ cpuguy83 Конечно, проблема. Мы не пытаемся монтировать файлы в каталог. Мы пытаемся смонтировать отдельный файл, созданный контейнером, на хост как файл.

Можем ли мы снова открыть эту проблему? По-прежнему не работает с 2019 года. На последней версии Docker и последней версии docker-compose, работающей на последней версии Debian.

Вы не можете подключиться из контейнера к хосту, только наоборот.
Это одинаковое поведение для каталогов и файлов.

Та же проблема, используя docker 19.03.1 и docker-compose 1.24.1, при попытке переопределить файл конфигурации в изображении store/elastic/filebeat:7.3.0 с привязкой тома в docker-compose.yml:

    volumes:
      - ${PWD}/filebeat.yml:/usr/share/filebeat/filebeat.yml:ro

ERROR: for docker_filebeat_1 Cannot start service filebeat: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:58: mounting \\\"/filebeat.yml\\\" to rootfs \\\"/var/lib/docker/overlay2/f49a0ae0ec6646c818dcf05dbcbbdd79fc7c42561f3684fbb1fc5d2b9d3ad192/merged\\\" at \\\"/var/lib/docker/overlay2/f49a0ae0ec6646c818dcf05dbcbbdd79fc7c42561f3684fbb1fc5d2b9d3ad192/merged/usr/share/filebeat/filebeat.yml\\\" 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

Сначала я пробовал использовать "конфиги", но выяснил, что эта функция предназначена только для роя.
Я пытаюсь найти способ предоставить файл конфигурации для образа по умолчанию, не создавая пользовательский с файлами конфигурации COPY.

Та же проблема

$ ls -l logstash.conf
-rw-r--r--  1 lubumbax  staff  164 Apr 30 18:01 logstash.conf
$ pwd
/Users/lubumbax/Src/Java/elk

$ docker run -it --name logstash -p 5000:5000 \
             -v "$(pwd)/logstash.conf:/usr/share/logstash/pipeline/logstash.conf" \
             docker.elastic.co/logstash/logstash:7.6.2

Результат:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/Users/lubumbax/Src/Java/elk/logstash.conf\\\" to rootfs \\\"/var/lib/docker/overlay2/bad85f1a2984bed23619fdf401cc9655573bb1799a8b681d371f5964201b9a82/merged\\\" at \\\"/var/lib/docker/overlay2/bad85f1a2984bed23619fdf401cc9655573bb1799a8b681d371f5964201b9a82/merged/usr/share/logstash/pipeline/logstash.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.

$ docker version
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.14
 Git commit:        afacb8b
 Built:             Thu Mar 12 02:45:41 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b7f0
  Built:            Wed Mar 11 01:30:32 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Есть ли шанс исправить это?

Раздражающая проблема.

Коллеги, проверьте направление монтирования в docker-compose.
У меня были те же проблемы, пока я не понял, что ошибался, должно быть так:

...
    volumes:
      - /host/file:/docker/file:ro
...