¡Sí, esto me está poniendo de nuevo!

¿Funciona después de fig kill y fig rm ? Tengo la sospecha de que es un error de Docker con VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

¿Funciona después de fig kill y fig rm ? Tengo la sospecha de que es un error de Docker con VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

no en realidad no,

El mismo error aquí al intentar usar volúmenes con un archivo ...

No funciona en un VFS aquí:

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

Pero funciona, funciona bien en mi computadora personal:

$ 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

Para los registros, la salida de la versión de Docker es la misma, pero estoy bastante seguro de que no es tan importante, ya que recuerdo que también funcionaba perfectamente en 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

Entonces, la única diferencia que puedo detectar es la versión del kernel. El primero (que no funciona) es un VFS, el segundo es mi computadora. ¿Eso ayuda a entender lo que está pasando?

Humm, perdón por la contaminación. Error tipográfico simple. No parece que yo sea el primero en ser atrapado por esto.

Si se llama a "-v" en una ubicación inexistente en el lado del host (debido a un error tipográfico), creará un directorio vacío y todo el directorio principal si es necesario. Luego, cuando intenta montar este directorio vacío en el contenedor y que un archivo ya está en la ubicación de destino, arroja este mensaje.

No creo que se deba permitir que Docker cree directorios en el lado del host. ¿Debo eliminar mi comentario anterior (¿y este?) Para evitar contaminar este hilo?

Agregaré mis dos centavos / golpearé este hilo. Sería muy útil poder agregar archivos individuales en docker-compose . En este momento tengo que tener un directorio separado para cada uno de mis contenedores, pero la mayoría de ellos solo tienen 1 o 2 archivos. Sería genial ponerlos todos en la misma carpeta y luego hacer referencia a ellos individualmente.

Creo que hubo un error en algún momento al hacer volúmenes, que incluían archivos montados en enlaces.
No creo que esto sea un problema hoy.

Este parece ser un problema recurrente.

Según la referencia de @ md5 y otros comentarios, puedo reproducir fielmente este comportamiento en las siguientes condiciones:

• CentOS 7
• Docker 1.5.0 (paquete yum docker-1.5.0-28.el7.centos)
• docker-compose 1.1.0

Este comportamiento no se presentó en el paquete yum docker-1.5.0-1.el7 .

Ejemplo:

Usando una declaración de servicio simple:

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

Al intentar enlazar montar un archivo en lugar de un directorio, docker-compose produce lo siguiente:

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

Sin embargo, el comando equivalente docker run tendrá éxito:

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

@dayglojesus Parece que está utilizando una versión de desarrollo de Docker.
¿Puede proporcionar la salida de docker version ?
El mensaje de error que tiene aquí es de esta confirmación: https://github.com/docker/docker/commit/b0ed2da4418d62d2d7b940b49e0e89bdcd264569

Esta confirmación no está en una versión de lanzamiento de Docker y tiene una corrección en el maestro, y es parte de la serie 1.6 RC.

@ cpuguy83 Informa que esta es la versión 1.5.0, no 1.6 RC:

Docker version 1.5.0-dev, build fc0329b/1.5.0

Esta es la compilación "oficial" disponible en los repositorios de yum de CentOS 7, sin ajustes para los repositorios de desarrollo.

¿Por qué docker-compose exhibe este comportamiento y docker run no? ¿Es esto un error en Docker o docker-compose ?

Hágame saber si necesita más información.

@dayglojesus Sí, esta no es una versión publicada de la ventana acoplable 1.5.0-dev se creó en algún momento después de que se cortara la ventana acoplable 1.5.0.
El error no existe en una versión publicada de Docker.

@ cpuguy83 Ya veo. Extraño, me pregunto cómo este paquete llegó al repositorio. ¿Sabe qué paquete de yum se correlaciona con la versión actual de Docker 1.5.0 para CentOS 7?

No estoy seguro ... ping @ lsm5

@dayglojesus, por lo que el que instaló es la ventana acoplable recompilada con RHEL que tiene algunos parches de redhat en la parte superior de la ventana acoplable ascendente. Si eso es algo que no le importa y solo quiere un rpm con docker ascendente, consulte: http://wiki.centos.org/Cloud/Docker . Esto menciona un repositorio adicional que contiene un rpm que construyo por separado como parte de CentOS virt SIG.

Si le importan las cosas de rhel allí, presente un error en https://bugzilla.redhat.com . HTH

Presentó un ticket de RHEL para este problema. https://bugzilla.redhat.com/show_bug.cgi?id=1209625
Gracias, @ lsm5.

Mmm, obtuve lo mismo en ubuntu 14.04lts con docker 1.5

me sucede en linux mint / ubuntu, los archivos no están montados en absoluto (se supone que deben sobrescribir el contenedor pero no lo hacen)

Tengo el mismo problema con etc-localtime en

• Linux guest.vm 3.13.0-49-generic # 81-Ubuntu
• x86_64 x86_64 x86_64 GNU / Linux
• Descripción: Ubuntu 14.04.2 LTS
• Lanzamiento: 14.04
• Nombre en clave: confiable
• Docker versión 1.5

Si tiene un problema, los +1 no ayudarán, especialmente porque lo más probable es que no estén relacionados en absoluto con el problema del OP.

Por favor, incluya qué comando Docker está ejecutando, qué espera ver y qué está viendo realmente.
También incluya la salida de docker info y docker version .
Gracias.

@ cpuguy83 ok, aquí está mi caso:

mando:

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 ...

situación: ~ / .gitconfig no está presente en el host antes de ejecutar ese comando

qué sucede: ~ / .gitconfig se crea como un directorio, propiedad de root (en lugar del usuario actual), y el contenedor no se ejecuta, deteniéndose con un mensaje sobre no poder montar ~ / .gitconfig (usando la ruta completa en su texto, no la tilde taquigráfica)

lo que espero ver: o bien la ventana acoplable debería crear ~ / .gitconfig como un archivo vacío, propiedad del usuario actual, e iniciar el contenedor con éxito, o negarse a comenzar con un mejor mensaje de error y sin haber creado ~ / .gitconfig en absoluto

información de Docker:

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 El problema aquí es que no hay forma de que detectemos que desea un archivo (esto se ha discutido antes).
En su secuencia de comandos de inicio, recomendaría agregar un touch ~/.gitconfig antes de su comando docker run .

:-D eso es lo que terminé haciendo.
¿Qué hay de tomar la ruta 2 y no crear la carpeta?

@gggeek Ese barco ha zarpado y sería un cambio

;-( Oh bien

Tengo este error con Docker version 1.6.0, build 4749651

Problema relacionado: https://github.com/docker/docker-py/issues/546

Creo que encontré una cosa relacionada para resolver este problema. Utilizo el último docker-compose (1.20) / docker (1.6.0) en AWS. Y recibía este error cada vez que intentaba iniciar nginx:

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

Desesperado, miré en nginx Dockerfile y vi que exponía un volumen. ¡Así que agregué este volumen a la lista que monté y de repente todo funcionó!

Entonces, la diferencia entre docker-compose y docker seams es el valor predeterminado para los volúmenes.

El problema se ha cerrado pero ¿cuál es la solución?
Tenemos el mismo problema de que no podemos montar archivos en un contenedor acoplable.
Última versión de Docker Toolbox (docker 1.9) en Windows
Comenzar el contenedor termina en

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

Igual que Sascha-Egeria, ¿una solución?

El problema que está informando no es el mismo que este. Este problema era un error en la versión anterior de Docker, que se solucionó hace mucho tiempo.

¿Quizás tu problema suena relacionado con el número 2268? Si pudiera publicar ese problema con la salida completa de docker-compose version , docker info , el contenido de su docker-compose.yml y los comandos que ejecutó, es posible que podamos depurar más la cuestión.

Finalmente resuelvo mi problema usando Git Bash y el comando "docker-machine ssh [MACHINE]" para trabajar con Docker.
El nuevo shell de Docker Quickstart Terminal (1.9d) en Windows funciona realmente mal.

Tengo el mismo problema.
Docker-componer: 1.5.1
Docker: 1.9.1

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

@ jordi12100 Si está obteniendo un directorio, entonces no pudo encontrar el archivo.

Reproducido en la ventana acoplable 1.9.1 intentando montar con server.conf:/etc/server.conf donde el archivo /etc/server.conf existe en una imagen.

El uso de una ruta relativa parece hacer que Docker considere el archivo host como el nombre de una carpeta. Dado que es un archivo en un contenedor y no podemos montar una carpeta en el archivo existente /etc/server.conf , falla.

El uso de una ruta absoluta a server.conf soluciona el problema docker run -v /absolute/path/to/server.conf:/etc/server.conf ... y Docker trata server.conf como un archivo habitual.

Las rutas relativas deben comenzar con . , así que intente ./server.config .

Sin él, se considera un volumen con nombre.

Tengo el mismo problema y no puedo montar el archivo incluso con . . Docker (¿o docker-compose?) Considera el archivo como una carpeta a menos que proporcione una ruta de archivo absoluta.

Docker: 1.9.1
Docker-componer: 1.5.2

Use ./server.conf:/etc/server.conf con trabajos de docker-compose. Pero la opción -v Docker CLI se queja de una ruta ilegal, solo acepta la ruta absoluta al archivo que se va a montar.

@kirisetsz correcto; docker-compose acepta rutas relativas (que son relativas al archivo docker-compose.yml ); Compose se encargará de la conversión de una ruta relativa a una ruta absoluta. Al usar Docker (no componer), debe especificar una ruta absoluta. Puede usar -v $(pwd)/server.conf:/etc/server.conf si no desea escribir la ruta completa

Confirmo, tengo el mismo problema con:
Mac OS X.10.11.3
Docker version 1.9.1, build a34a1d5
docker-compose version 1.5.2, build 7240ff3
Incluso si especifico una ruta de host absoluta o relativa, tengo la misma respuesta:
ERROR: Cannot start container a9ed08a3ee639f61ff2720745011c940a5fff5b9b98bda6a45156a80381c5328: [8] System error: not a directory
FYI:

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

Yo tambien estoy teniendo este problema

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

En este ejemplo, auth.json se crea como un directorio en la máquina host y debería ser un archivo. Si primero coloco auth.json en la máquina host, se queja de que no es un directorio.

Para mí también cuando intento:

volúmenes:
- ./docker/default.conf:/etc/nginx/conf.d/default.conf

Recibo el error: ERROR: No se puede iniciar el contenedor 9f ...... f1e: [9] Error del sistema: no es un directorio

Si cambio conf.d a otra cosa, funciona pero monta default.conf como directorio en lugar de archivo

Windows 10
Versión de Docker: 1.10.1
docker-compose versión 1.6.0, compilación cdb920a

¿Se puede volver a abrir este error, por favor, ya que se cerró sin una resolución? Todavía está sucediendo. Mi caso es el mismo que el de muchos otros, intentando montar un archivo nginx.conf en la imagen nginx en /etc/nginx/nginx.conf.

En 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"

Salida:

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

Estoy ejecutando Docker en OS X (10.11.3) usando una máquina virtual Vagrant con el complemento VMware Fusion (VMware Fusion 8.1.0) y un host CoreOS. Información de versión relevante:

$ 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

Consulte mi comentario aquí: https://github.com/docker/compose/issues/424#issuecomment -157751229

El error puede parecer el mismo, pero lo más probable es que se deba a un problema diferente.

Consulte también https://github.com/docker/docker/issues/13670 y https://github.com/docker/docker/issues/19304.

También he escuchado informes de que puede obtener esto si el directorio de trabajo que ha configurado no existe como directorio. Creo que se está enfrentando a uno de estos problemas.

Intente usar https://github.com/brikis98/docker-osx-dev

Encontré este problema y, después de arrancarme los pelos, descubrí que la carpeta era un enlace simbólico a una carpeta raíz.

Se movió todo el contenido a (mi) carpeta propiedad del usuario y funciona bien.

Docker-1.12.0-rc2
Docker-máquina 0.8.0-rc1
Docker-compose 1.8.0-rc1

Encontré este hilo a través de Google. Yo también tengo este problema. No puedo enlazar a archivos individuales, OSX.

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

Docker se actualizó hoy.

Actualización: captura de pantalla que muestra que intenta montar como directorio, no como archivo.

Tengo el mismo problema :-( no puedo montar un solo archivo

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

también confirmando el problema

La actualización de hoy en OSX lo ha solucionado. Pude montar con éxito un solo archivo usando docker-compose.

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

Intenté montar un archivo con docker-compose

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

En la máquina host

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 creó un directorio: drwxr-xr-x app.conf
en lugar de un archivo.

¿Es este un comportamiento normal? Supuse que el archivo sería creado y montado.

Estaré muy agradecido si alguien me da una aclaración.

# 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 si el archivo o directorio que está intentando enlazar-montar no existe, Docker no tiene forma de determinar si está esperando un _file_ o un _directory_, en ese caso (si /usr/src/app/app.conf no exist), el demonio de la ventana acoplable crea un directorio en esa ubicación y lo enlaza y lo monta en el contenedor.

Tenga en cuenta que intentamos desaprobar / eliminar la creación automática de la ruta (y producir un error en su lugar), pero este fue un cambio demasiado retrocompatible (algunas personas confían en este comportamiento), por lo que tuvimos que mantener este comportamiento.

@thaJeztah ¡ Gracias por una respuesta rápida!
Intenté crear un archivo "/usr/src/app/app.conf" manualmente antes de iniciar docker-compose y el resultado es el siguiente:

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 ¿cuál es tu configuración? ¿Tanto el demonio como el cliente se ejecutan en la misma computadora, o está trabajando con un demonio remoto (o un demonio que se ejecuta en una máquina virtual?)

@thaJeztah Estoy usando el host DO, Ubuntu 16.04 LTS,
docker-compose y docker instalados en él, encuentre las versiones a continuación:

# 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

todo se está ejecutando en esta máquina hasta allí estoy conectado usando ssh

Tratando de sacar de la ecuación la composición de Docker, puedes intentar reproducir con;

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

que debería enlazar-montar el archivo de configuración e imprimir su contenido

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 También podría ejecutar algún docker-compose.yml si me lo das con fines de prueba

@bogulean correcto, entonces parece ser un problema con docker-compose, o con la imagen que está construyendo / ejecutando. Este sería el equivalente a la prueba anterior, pero luego a través de docker-compose;

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

Y para probar si funciona;

docker-compose run web

(que también debería imprimir Hello from /usr/src/app/app.conf )

@thaJeztah , ¡Muchas gracias! Su docker-compose.yml devolvió Hello from /usr/src/app/app.conf
Eso me hizo darme cuenta de que estaba haciendo algo mal en otro lugar y descubrí que había una línea en mi Dockerfile:
VOLUME ["/usr/src/app.conf"]
lo eliminó y el archivo comenzó a unirse como se esperaba.

Gracias por tu tiempo.

¡Es bueno escucharlo y feliz de ayudar!

El problema en su caso es que VOLUME también espera un directorio, por lo que creó un volumen e intentó montarlo en /usr/src/app.conf . La mejor manera de trabajar con archivos individuales desde el host suele ser tener en cuenta esta situación, por ejemplo, teniendo un directorio /usr/src/config/ ; luego enlazaría-monte (o usaría un volumen) para ese directorio, en lugar del archivo. Obviamente, no siempre es posible

@thaJeztah , tengo el mismo problema al ejecutar esto:

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

/ definitivamente existe dentro de la imagen / contenedor:

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

Parece ser un error de Docker en general, no relacionado con Docker Compose.
No estoy seguro de por qué Docker crearía un directorio en este caso.

¿Algunas ideas? ¡Muchas gracias!

También probé tu ejemplo con la imagen alpina. Mismo. cat: read error: Is a directory

@thasmo Está recibiendo este error porque filebeat.yml es un directorio, no un archivo.
Debe asegurarse de que el archivo exista en el host antes de intentar montarlo en el contenedor; de lo contrario, Docker creará un directorio por usted.

@ cpuguy83 , creo que acabo de encontrar el problema. Estoy usando Docker en Windows a través de Docker Machine y VirtualBox y probablemente no pueda montar el archivo local a través de VirtualBox en el contenedor.
https://docs.docker.com/docker-for-windows/troubleshoot/#/host -filesystem-sharing

Encontré ese problema en la ventana acoplable de instalación limpia en la actualización de aniversario de Windows 10.
De hecho, este problema es una solución muy simple.

Necesita compartir unidades en las opciones de Docker http://www.awesomescreenshot.com/image/1510321/0f1a81d7a8883df5a61bcdf04b3994cf
Busca, encuentra y resuelve el problema.

Aún tengo el problema en 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".

Si cambié la ejecución de la ventana acoplable para montar en un archivo que no existe como / tmp / foo, funciona pero monta un directorio.

@djpate, ¿su demonio docker se ejecuta en el mismo host (y no en una máquina virtual?). Si /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf no existe en la máquina en la que se está ejecutando el demonio de la ventana acoplable, el demonio creará un _directorio_ con ese nombre e intentará montarlo en /etc/resolv.conf dentro del contenedor. Dado que /etc/resolv.conf es un _archivo_, el montaje de enlace de un directorio encima de un archivo fallará.

Habiendo dicho eso, desaconsejaría sobreescribir /etc/resolv.conf con un archivo local; /etc/resolv.conf es administrado por Docker para configurar el servidor DNS correcto para usar. Docker tiene un servidor DNS integrado para la detección de servicios, por lo que anular ese archivo hará que la detección de servicios no funcione.

Si desea configurar las opciones de DNS, use las opciones --dns , --dns-opt y --dns-search en 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 [])

Esto establecerá esas opciones sin causar resultados inesperados. Tenga en cuenta que el DNS dentro del contenedor siempre será 127.0.0.11 (el servidor DNS integrado), pero ese servidor reenvía automáticamente las solicitudes al servidor DNS que especificó con --dns

@thaJeztah Soy nuevo en Docker, pero creo que se está ejecutando en mi máquina. Básicamente instalé docker-engine y docker-machine en una máquina local ubuntu normal. Este es el entorno de desarrollo de mi empresa y parece funcionar para todos en una ventana acoplable Mac.

Lo cambiaré a la opción DNS como mencionaste, no estaba al tanto de esto. ¡Gracias! Pero creo que el error sigue ahí.

Esto tampoco me funciona en docker-compose v1.6.2 y docker v1.10.2 :(

El uso de rutas absolutas funciona, pero desafortunadamente para mi caso de uso, las rutas absolutas no funcionarán :(. He probado todas las combinaciones de ./ y ../ que se me ocurren.

EDITAR: También estoy ejecutando Linux sin VM, por lo que la solución

El sistema operativo es Ubuntu 14.04

Docker está a la 1.13.1 ahora. Actualice su Docker. Ha estado funcionando, desde 1.12.x.

Ah gracias. Actualizará la ventana acoplable y se actualizará si / cuando se solucione :)

EDITAR: ¡Funcionó! Gracias @guice

@thaJeztah

Si el archivo o directorio que está tratando de vincular-montar no existe, Docker no tiene forma de determinar si está esperando un archivo o directorio, en ese caso (si /usr/src/app/app.conf no 't existe), el demonio de la ventana acoplable crea un directorio en esa ubicación y lo monta en el contenedor.
Tenga en cuenta que intentamos desaprobar / eliminar la creación automática de la ruta (y producir un error en su lugar), pero este fue un cambio demasiado retrocompatible (algunas personas confían en este comportamiento), por lo que tuvimos que mantener este comportamiento.

Estoy bastante frustrado después de seis horas de probar exactamente este caso de uso y ahora descubrir que es imposible.
¿Por qué no agregar algo como "bandera de archivo" a la declaración de volumen, considerando que podemos especificar opciones de montaje adicionales como :ro y :rw ?

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

Cuando estoy mapeando un archivo contenedor a un archivo host, espero que el archivo host se cree (copie del contenedor) en la inicialización del contenedor.
Desafortunadamente, es bastante común encontrar contenedores con archivos de configuración colocados directamente en el directorio raíz de la aplicación, y obviamente no desea "voluminizar" la raíz completa. En ese caso, sería especialmente útil si esto funcionara.

@malyzeli, es posible que desee ver los secretos como una forma de inyectar una configuración como esta, o crear plantillas al inicio.
Los volúmenes están realmente diseñados para la persistencia, no para la configuración.
Realmente, Docker no debería crear automáticamente rutas de host en absoluto, y este comportamiento se ha eliminado en las API más nuevas.

@ cpuguy83

No entiendo su punto, así que explique o corrija mis suposiciones, porque soy bastante nuevo en el ecosistema Docker.

Es posible que desee ver los secretos como una forma de inyectar una configuración como esta, o crear plantillas al inicio.

¿Qué pasa si no sé cómo se verá el archivo de configuración, porque es creado por algún asistente de instalación directamente desde la aplicación (y que eventualmente cambia de una versión a otra)?
Muchas aplicaciones tienen este tipo de configuración inicial, por ejemplo, Limesurvey y NodeBB.

Los volúmenes están realmente diseñados para la persistencia, no para la configuración.

¿Está insinuando que la configuración del contenedor existente no debe ser persistente?
Entonces, ¿qué pasa si quiero hacer una copia de seguridad de alguna parte de mi infraestructura de contenedores múltiples?
Quiero tener tanto los datos como la configuración en volúmenes para poder restaurarlos rápidamente si sucede algo malo.

Realmente, Docker no debería crear automáticamente rutas de host en absoluto, y este comportamiento se ha eliminado en las API más nuevas.

En realidad, no lo necesito para crear rutas de host, sino para inicializar un volumen dado con datos de imagen existentes (por ejemplo, "externalizar" algunas plantillas html, que quiero que se puedan editar desde el sistema host y / u otro contenedor), y aún así funciona exactamente como se indica en la referencia de Dockerfile :

El comando docker run inicializa el volumen recién creado con cualquier dato que exista en la ubicación especificada dentro de la imagen base.

¿Qué pasa si no sé cómo se verá el archivo de configuración, porque es creado por algún asistente de instalación directamente desde la aplicación (y que eventualmente cambia de una versión a otra)?

Deje que se cree, extráigalo de la imagen / contenedor, haga un secreto

Quiero tener tanto los datos como la configuración en volúmenes para poder restaurarlos rápidamente si sucede algo malo.

Usa secretos. También estamos viendo un objeto config dedicado que es similar a los secretos, pero no tan restringido ... pero hoy los secretos son lo que está disponible.

En realidad, no lo necesito para crear rutas de host, sino para inicializar un volumen dado con datos de imagen existentes (por ejemplo, "externalizar" algunas plantillas html, que quiero que se puedan editar desde el sistema host y / u otro contenedor), y aún así funciona exactamente como se indica en la referencia de Dockerfile:

Los montajes de enlace no son volúmenes. La referencia de Dockerfile habla de volúmenes. Es lamentable que se use docker run -v para ambos.

Definitivamente no estoy diciendo que no use volúmenes para almacenar la configuración, estoy diciendo que debe evaluar si hay una mejor solución (y los secretos de la OMI son mucho mejores para esto).

Los enlaces de host son una mala solución para cualquier otra cosa que no sea tomar algo que ya existe en el host y meterlo en el contenedor ... e incluso entonces, generalmente no es viable cuando se habla de entornos en clúster.

@ cpuguy83

Deje que se cree, extráigalo de la imagen / contenedor, haga un secreto

Sí, eso es lo que hago, pero parece muy complicado de todos modos ... :-)

Usa secretos. También estamos viendo un objeto config dedicado que es similar a los secretos, pero no tan restringido ... pero hoy los secretos son lo que está disponible.

Lo investigaré, no sabía sobre secretos, ¡gracias!

Los montajes de enlace no son volúmenes. La referencia de Dockerfile habla de volúmenes. Es lamentable que se use docker run -v para ambos.

Bien, eso parece ser una explicación de por qué no funcionó como esperaba. Pensé que los enlaces y los volúmenes tienen nombres diferentes para lo mismo, considerando que se hace a través del mismo -v .

Para aquellos que ven este error en Windows ... incluso si tiene Drives Shared ...

Existe un problema en el que si usa Docker Windows (con docker-compose) y usa ciertas credenciales para "Compartir unidad" como C: \ o D: \ etc., es posible que deba dejar de compartir, compartir la unidad nuevamente, volver a ingresar credenciales, de lo contrario, le da un error relacionado como:

"ERROR: para ... No se puede iniciar el servicio su servicio: error de tiempo de ejecución de oci: container_linux.go: 262: el proceso de inicio del contenedor provocó" process_linux.go: 339: container "provocó \" rootfs_linux.go: 57: montaje \

"\\" provocó \\ "no es un directorio \\" ""
: ¿Está intentando montar un directorio en un archivo (o viceversa)? Compruebe si la ruta de host especificada existe y es del tipo esperado "

BaranOrnarli ¿cómo ser el que tiene DockerToolbox?

El mismo problema aquí que la mayoría de la gente aquí. Pero lo hice funcionar nuevamente simplemente reiniciando la VM.

Educación de Windows 10
Caja de herramientas de Docker, 17.10.0-ce
VirtualBox 5.2.2

Ejecutar esto a través de Docker CLI funciona:
docker run -d -p 8080:80 -v $(pwd)/src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf tutorial / nginx

Ejecutando lo mismo a través de docker-compose, no:
recorte
volumes: - ./src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf
Es decir, hasta que apague la máquina virtual a través de la GUI de VirtualBox y vuelva a iniciar la Terminal de inicio rápido de Docker.

Desde entonces, destruir repetidamente los contenedores y docker-compose no hizo que el error volviera.

Espero que esto ayude a alguien.

Tengo el mismo problema. Mientras tanto, estoy usando la carpeta acoplable de volúmenes reales en docker-compose.yml. Esta es /var/lib/docker/volumes..../file.ext como solución temporal
(Docker versión 17.12.0-ce, compilación c97c6d6)

Si tiene ese problema, también verifique si compartió su directorio en Windows.

Estoy en ubuntu 14.04. Cuando ejecuto el comando docker-compose up -d , aparece el siguiente error:

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

Estoy usando la ruta absoluta para mapear el volumen /home/curso-docker/email-worker-compose/nginx/default.conf de mi host.

¿Alguien tiene idea de este problema?

@AzeredoGabriel para mí, hacer lo que @BaranOrnarli mencionó antes funcionó de

¿Alguna noticia sobre esto? Todavía parece imposible montar un solo archivo

@Karlheinzniebuhr Esto nunca fue un problema. Docker permite montar archivos en un contenedor, pero no puede montar un archivo en un directorio o viceversa.

¿Alguna noticia sobre esto? Todavía parece imposible montar un solo archivo

intente mapear el archivo con el directorio existente. Docker intenta crear directorio siempre si no existe.

@ cpuguy83 Por supuesto que es un problema. No estamos intentando montar archivos en un directorio. Estamos intentando montar un solo archivo creado por el contenedor en el host como un archivo.

¿Podemos reabrir este problema? Todavía no funciona a partir de 2019. En el último Docker y el último docker-compose que se ejecuta en la última versión de Debian.

No puede montar desde el contenedor al host, solo al revés.
Este es el mismo comportamiento para directorios y archivos.

El mismo problema, usando docker 19.03.1 y docker-compose 1.24.1, al intentar anular un archivo de configuración en store/elastic/filebeat:7.3.0 image con enlace de volumen en 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

Inicialmente intenté usar "configs" pero descubrí que esta función es solo para enjambres.
Estoy tratando de encontrar una manera de proporcionar un archivo de configuración a la imagen predeterminada sin crear uno personalizado con archivos de configuración COPY.

Mismo problema

$ 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

Resultado:
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

¿Alguna posibilidad de arreglar esto?

Problema molesto.

Compañeros, verifiquen la dirección de montaje en docker-compose.
Tuve los mismos problemas hasta que me di cuenta de que estaba equivocado, debería ser así:

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