Sim, isso está me colocando de volta!

Funciona depois de fig kill e fig rm ? Suspeito que seja um bug do Docker com VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

Funciona depois de fig kill e fig rm ? Suspeito que seja um bug do Docker com VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

Não, na verdade não,

Mesmo erro aqui ao tentar usar volumes com um arquivo ...

Não funciona em um VFS aqui:

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

Mas funciona bem no meu computador pessoal:

$ 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 os registros, a saída da versão do docker é a mesma, mas tenho quase certeza de que não é tão importante, pois me lembro que estava funcionando perfeitamente também no 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

Portanto, a única diferença que consigo identificar é a versão do kernel. O primeiro (que não funciona) é um VFS, o segundo é o meu computador. Isso ajuda a entender o que está acontecendo?

Humm, desculpe pela poluição. Erro de digitação simples. Não parece que sou o primeiro a ser pego por isso.

Se "-v" for chamado em um local inexistente no lado do host (devido a um erro de digitação), ele criará um diretório vazio e todos os diretórios pais, se necessário. Então, quando ele tenta montar esse diretório vazio no contêiner e que um arquivo já está no local de destino, ele lança esta mensagem.

Não acho que o docker deva ter permissão para criar diretórios no lado do host. Devo excluir meu comentário anterior (e este?) Para evitar poluir este tópico?

Vou adicionar meus dois centavos / bump neste tópico. Seria muito útil poder adicionar arquivos individuais em docker-compose . No momento, preciso ter um diretório separado para cada um dos meus contêineres, mas a maioria deles tem apenas 1 ou 2 arquivos. Seria ótimo colocá-los todos na mesma pasta e, em seguida, referenciá-los individualmente.

Acho que houve um bug em algum ponto em torno de fazer volumes, que incluía arquivos montados em bind.
Não acho que isso seja um problema hoje.

Este parece ser um problema recorrente.

De acordo com a referência de @ md5 e outros comentários, posso reproduzir fielmente esse comportamento nas seguintes condições:

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

Este comportamento não estava presente no pacote yum docker-1.5.0-1.el7 .

Exemplo:

Usando uma declaração de serviço simples:

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

Na tentativa de vincular a montagem de um arquivo em vez de um diretório, docker-compose produz o seguinte:

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

Ainda assim, o comando docker run equivalente terá sucesso:

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

@dayglojesus Você parece estar usando uma versão de desenvolvimento do Docker.
Você pode fornecer a saída de docker version ?
A mensagem de erro que você tem aqui é deste commit: https://github.com/docker/docker/commit/b0ed2da4418d62d2d7b940b49e0e89bdcd264569

Este commit não está em uma versão lançada do Docker e tem uma correção no master, e faz parte da série 1.6 RC.

@ cpuguy83 Ele relata que esta é a versão 1.5.0, não 1.6 RC:

Docker version 1.5.0-dev, build fc0329b/1.5.0

Esta é a compilação "oficial" disponibilizada nos repositórios CentOS 7 yum, sem ajustes para repositórios dev.

Por que docker-compose exibe esse comportamento e docker run não? É um bug no Docker ou docker-compose ?

Deixe-me saber se você precisar de mais informações.

@dayglojesus Sim, esta não é uma versão lançada do docker 1.5.0-dev foi construído algum tempo depois que o docker 1.5.0 foi cortado.
O bug não existe em uma versão lançada do docker.

@ cpuguy83 entendo. Estranho, eu me pergunto como esse pacote foi parar no repo. Por acaso você sabe qual pacote yum se correlaciona com a versão real do Docker 1.5.0 para CentOS 7?

Não tenho certeza ... ping @ lsm5

@dayglojesus, então o que você instalou é o docker recompilado pelo RHEL que tem alguns patches redhat na parte superior do docker upstream. Se isso é algo com que você não se preocupa e só quer um rpm com docker upstream, consulte: http://wiki.centos.org/Cloud/Docker . Isso menciona um repositório adicional que contém um rpm que eu construo separadamente como parte do CentOS virt SIG.

Se você se preocupa com as coisas do rhel lá, registre um bug em https://bugzilla.redhat.com . HTH

Arquivou um tíquete RHEL para este problema. https://bugzilla.redhat.com/show_bug.cgi?id=1209625
Obrigado, @ lsm5.

Mmm, obtive a mesma coisa no ubuntu 14.04lts com docker 1.5

acontece comigo no linux mint / ubuntu, os arquivos não são montados (eles deveriam sobrescrever o contêiner, mas não)

Tenho o mesmo problema com etc-localtime em

• Linux guest.vm 3.13.0-49-generic # 81-Ubuntu
• x86_64 x86_64 x86_64 GNU / Linux
• Descrição: Ubuntu 14.04.2 LTS
• Lançamento: 14.04
• Codename: trusty
• docker versão 1.5

Se você estiver tendo um problema, os + 1s não ajudarão, especialmente porque provavelmente não estão relacionados ao problema do OP.

Inclua o comando do docker que está executando, o que espera ver e o que realmente está vendo.
Inclua também a saída de docker info e docker version .
Obrigado.

@ cpuguy83 ok, aqui está o meu caso:

comando:

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

situação: ~ / .gitconfig não está presente no host antes de executar esse comando

o que acontece: ~ / .gitconfig é criado como um dir, pertencente ao root (em vez do usuário atual), e o contêiner não é executado, parando com uma mensagem sobre não ser capaz de montar ~ / .gitconfig (usando o caminho completo em seu texto, não a abreviação de til)

o que espero ver: o docker deve criar ~ / .gitconfig como um arquivo vazio, pertencente ao usuário atual, e iniciar o contêiner com sucesso, ou se recusar a iniciar com uma mensagem de erro melhor e sem ter criado ~ / .gitconfig

informações do 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 O problema aqui é que não há como detectarmos que você deseja um arquivo (isso já foi discutido antes).
Em seu script de início, eu recomendaria adicionar touch ~/.gitconfig antes de seu comando docker run .

:-D foi o que acabei fazendo.
Que tal seguir a rota 2 e não criar a pasta?

@gggeek Esse navio partiu e seria uma mudança significativa, infelizmente.

;-( Ah bem

Eu tenho este bug com Docker version 1.6.0, build 4749651

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

Acho que encontrei uma coisa relacionada para resolver esse problema. Eu uso o docker-compose (1.20) / docker (1.6.0) mais recente no AWS. E recebia este erro sempre que tentava iniciar o nginx:

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

Desesperado, olhei para o nginx Dockerfile e vi que ele expunha um volume. Então eu adicionei este volume à lista que montei e de repente tudo funcionou!

Portanto, a diferença entre docker-compose e docker parece ser o valor padrão dos volumes.

O problema foi resolvido, mas qual é a solução?
Temos o mesmo problema de que não podemos montar arquivos em um contêiner do docker.
Versão mais recente do Docker Toolbox (docker 1.9) no Windows
Iniciar o contêiner termina em

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

Igual a Sascha-Egeria, uma solução?

O problema que você está relatando não é igual a este. Esse problema era um bug na versão anterior do Docker, que foi corrigido há muito tempo.

O seu problema parece estar relacionado com # 2268, talvez? Se você pudesse postar nesse problema com a saída completa de docker-compose version , docker info , o conteúdo de seu docker-compose.yml e os comandos que você executou, poderemos depurar mais o problema.

Finalmente resolvi meu problema usando Git Bash e o comando "docker-machine ssh [MACHINE]" para trabalhar com o Docker.
O novo shell do Docker Quickstart Terminal (1.9d) no Windows funciona muito mal.

Estou tendo o mesmo problema.
Docker-compose: 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 Se você está obtendo um diretório, ele não conseguiu localizar o arquivo.

Reproduzido no docker 1.9.1 tentando montar com server.conf:/etc/server.conf onde o arquivo /etc/server.conf existe em uma imagem.

Usar um caminho relativo parece fazer o docker considerar o arquivo host como o nome de uma pasta. Como é um arquivo em um contêiner e não podemos montar uma pasta no arquivo existente /etc/server.conf , ele falha.

Usar um caminho absoluto para server.conf corrige o problema para mim docker run -v /absolute/path/to/server.conf:/etc/server.conf ... e o docker trata server.conf como um arquivo normal.

Caminhos relativos devem começar com . , então tente ./server.config .

Sem ele, é considerado um volume nomeado.

Eu tenho o mesmo problema e não consigo montar o arquivo, mesmo com um . . Docker (ou docker-compose?) Considera o arquivo como uma pasta, a menos que eu forneça um caminho de arquivo absoluto.

Docker: 1.9.1
Docker-compose: 1.5.2

Use ./server.conf:/etc/server.conf com trabalhos docker-compose. Mas a opção -v docker CLI reclama sobre o caminho ilegal, aceita apenas o caminho absoluto para o arquivo a ser montado.

@kirisetsz correct; docker-compose aceita caminhos relativos (que são relativos ao arquivo docker-compose.yml ); Compose cuidará da conversão de um caminho relativo em um caminho absoluto. Ao usar o docker (não compor), você deve especificar um caminho absoluto. Você pode usar -v $(pwd)/server.conf:/etc/server.conf se não quiser digitar todo o caminho

Confirmo, tenho o mesmo problema com:
Mac OS X.10.11.3
Docker version 1.9.1, build a34a1d5
docker-compose version 1.5.2, build 7240ff3
Mesmo se eu especificar um caminho de host absoluto ou relativo, tenho a mesma resposta:
ERROR: Cannot start container a9ed08a3ee639f61ff2720745011c940a5fff5b9b98bda6a45156a80381c5328: [8] System error: not a directory
PARA SUA INFORMAÇÃO:

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

Eu também estou tendo esse 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

Neste exemplo, auth.json é criado como um diretório na máquina host e deve ser um arquivo. Se eu colocar o auth.json na máquina host, ele reclamará que não é um diretório.

Para mim também quando tento:

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

Recebo o erro: ERRO: Não é possível iniciar o contêiner 9f ...... f1e: [9] Erro do sistema: não é um diretório

Se eu mudar conf.d para outra coisa, ele funciona, mas monta default.conf como diretório em vez de arquivo

Windows 10
Versão docker: 1.10.1
docker-compose versão 1.6.0, compilação cdb920a

Esse bug pode ser reaberto, por favor, já que foi fechado sem uma resolução? Ainda está acontecendo. Meu caso é o mesmo de muitos outros, tentando montar um arquivo nginx.conf na imagem nginx em /etc/nginx/nginx.conf.

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

Resultado:

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

Estou executando o Docker no OS X (10.11.3) usando uma VM Vagrant com o plugin VMware Fusion (VMware Fusion 8.1.0) e um host CoreOS. Informações relevantes sobre a versão:

$ 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

Por favor, veja meu comentário aqui: https://github.com/docker/compose/issues/424#issuecomment -157751229

O erro pode parecer o mesmo, mas provavelmente é causado por um problema diferente.

Consulte também https://github.com/docker/docker/issues/13670 e https://github.com/docker/docker/issues/19304.

Também ouvi relatos de que você pode obter isso se o diretório de trabalho definido não existir como um diretório. Eu acredito que você está encontrando um desses problemas.

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

Eu encontrei esse problema e depois de tirar todo o meu cabelo descobri que a pasta era um link simbólico para uma pasta de propriedade do root.

Todo o conteúdo foi movido para a (minha) pasta de propriedade do usuário e funciona bem.

Docker-1.12.0-rc2
Docker-machine 0.8.0-rc1
Docker-compose 1.8.0-rc1

Encontrei este tópico através do Google. Também estou tendo esse problema. Não consigo vincular a arquivos únicos, OSX.

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

Docker acabou de ser atualizado hoje.

Atualização: captura de tela mostrando a tentativa de montagem como um diretório, não como um arquivo.

Tenho o mesmo problema :-( não consigo montar um único arquivo

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

também confirmando o problema

A atualização de hoje no OSX corrigiu isso. Consegui montar com sucesso um único arquivo usando docker-compose.

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

Tentei montar um arquivo com docker-compose

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

Na 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 criou um dir: drwxr-xr-x app.conf
em vez de um arquivo.

Este é um comportamento normal? Suponho que o arquivo seja criado e montado.

Ficarei muito grato se alguém me der um esclarecimento.

# 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 se o arquivo ou diretório que você está tentando fazer bind-mount não existe, o docker não tem como determinar se você está esperando um _file_ ou um _directory_, nesse caso (se /usr/src/app/app.conf não existir), o daemon do docker cria um diretório nesse local e o monta por bind no contêiner.

Observe que tentamos descontinuar / remover a criação automática do caminho (e, em vez disso, produzir um erro), mas essa era uma alteração incompatível com versões anteriores (algumas pessoas contam com esse comportamento), então tivemos que manter esse comportamento.

@thaJeztah Obrigado pela resposta rápida!
Tentei criar um arquivo "/usr/src/app/app.conf" manualmente antes de iniciar o docker-compose e o resultado está abaixo:

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 qual é a sua configuração? O daemon e o cliente estão em execução no mesmo computador ou você está trabalhando com um daemon remoto (ou um daemon em execução em uma máquina virtual?)

@thaJeztah estou usando o host DO, Ubuntu 16.04 LTS,
docker-compose e docker instalados nele, encontre as versões abaixo:

# 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

tudo esta rodando nesta maquina para la estou conectado usando ssh

Tentando tirar a composição docker da equação, você pode tentar reproduzir com;

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

que deve ligar-montar o arquivo de configuração e imprimir seu conteúdo

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 eu também poderia executar alguns docker-compose.yml se você me der para fins de teste

@bogulean certo, então parece ser um problema com docker-compose ou com a imagem que você está construindo / executando. Isso seria o equivalente ao teste anterior, mas por meio de docker-compose;

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

E para tentar se funciona;

docker-compose run web

(que também deve imprimir Hello from /usr/src/app/app.conf )

@thaJeztah , muito obrigado! Seu docker-compose.yml retornou Hello from /usr/src/app/app.conf
Isso me fez perceber que estou fazendo algo errado em outro lugar e descobri que havia uma linha em meu Dockerfile:
VOLUME ["/usr/src/app.conf"]
removeu-o e o arquivo começou a vincular conforme o esperado.

Obrigado pelo seu tempo.

É bom ouvir e feliz em ajudar!

O problema no seu caso, é que VOLUME também espera um diretório, então criei um volume e tentei montá-lo em /usr/src/app.conf . A melhor maneira de trabalhar com arquivos únicos do host é normalmente levar esta situação em consideração, por exemplo, tendo um diretório /usr/src/config/ ; você então vinculará a montagem (ou usará um volume) para esse diretório, em vez do arquivo. Obviamente, nem sempre é possível

@thaJeztah , tenho o mesmo problema ao executar isso:

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

/ definitivamente existe dentro da imagem / contêiner:

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 um bug do Docker em geral, não relacionado ao Docker Compose.
Não sei por que o Docker criaria um diretório neste caso.

Alguma ideia? Muito obrigado!

Também tentei seu exemplo com a imagem alpina. Mesmo. cat: read error: Is a directory

@thasmo Você está recebendo este erro porque filebeat.yml é um diretório, não um arquivo.
Você deve certificar-se de que o arquivo existe no host antes de tentar montá-lo no contêiner, caso contrário, o docker criará um diretório para você.

@ cpuguy83 , acho que acabei de encontrar o problema. Estou usando o Docker no Windows via Docker Machine e VirtualBox e provavelmente não é possível montar o arquivo local por meio do VirtualBox no contêiner.
https://docs.docker.com/docker-for-windows/troubleshoot/#/host -filesystem-sharing

Eu encontrei esse problema na janela de encaixe de instalação limpa na atualização de aniversário do Windows 10.
Na verdade, este problema é uma solução muito simples

Precisa compartilhar unidades nas opções do docker http://www.awesomescreenshot.com/image/1510321/0f1a81d7a8883df5a61bcdf04b3994cf
Procura encontrar e resolve o problema.

Ainda tendo o problema no 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".

Se eu alterei o docker run para montar em um arquivo que não existe como / tmp / foo, ele funcionará, mas montará um diretório.

@djpate seu daemon do docker está rodando no mesmo host (e não em uma máquina virtual?). Se /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf não existir na máquina em que o daemon do docker está sendo executado, o daemon criará um _diretório_ com esse nome e tentará montá-lo em /etc/resolv.conf dentro do contêiner. Como /etc/resolv.conf é um _arquivo_, a montagem de um diretório no topo de um arquivo falhará.

Dito isso, eu desaconselho fortemente substituir /etc/resolv.conf por um arquivo local; /etc/resolv.conf é gerenciado pelo docker para definir o servidor DNS correto a ser usado. O Docker tem um servidor DNS integrado para descoberta de serviço, portanto, substituir esse arquivo fará com que a descoberta de serviço não funcione.

Se você quiser definir as opções de DNS, use as opções --dns , --dns-opt e --dns-search em 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 [])

Isso definirá essas opções sem causar resultados inesperados. Observe que o DNS dentro do contêiner sempre será 127.0.0.11 (o servidor DNS embutido), mas esse servidor encaminha automaticamente as solicitações para o servidor DNS especificado com --dns

@thaJeztah Sou novo no docker, mas acho que ele está rodando na minha máquina. Basicamente, instalei o docker-engine e o docker-machine em uma máquina local comum do Ubuntu. Este é o dev env da minha empresa e parece funcionar para todos em um Mac docker.

Vou mudar para a opção DNS como você mencionou, eu não sabia disso. Obrigado! Mas o bug ainda está lá, eu acho.

Isso também não está funcionando para mim no docker-compose v1.6.2 e docker v1.10.2 :(

Usar caminhos absolutos funciona, mas, infelizmente, para meu caso de uso, caminhos absolutos absolutamente não funcionam :(. Eu tentei todas as combinações de ./ e ../ que consigo pensar.

EDIT: Também estou executando em Linux sem VMs, então a solução @thaJeztah não funciona para mim

SO é Ubuntu 14.04

Docker é até 1.13.1 agora. Atualize seu Docker. Está funcionando, desde 1.12.x.

Ah obrigado. Irá atualizar o docker e atualizar se / quando corrigido :)

EDIT: funcionou! Obrigado @guice

@thaJeztah

Se o arquivo ou diretório que você está tentando ligar-montar não existe, o docker não tem como determinar se você está esperando um arquivo ou diretório, nesse caso (se /usr/src/app/app.conf não não existir), o daemon do docker cria um diretório nesse local e o monta no contêiner.
Observe que tentamos descontinuar / remover a criação automática do caminho (e, em vez disso, produzir um erro), mas essa era uma alteração incompatível com versões anteriores (algumas pessoas contam com esse comportamento), então tivemos que manter esse comportamento.

Estou bastante frustrado depois de seis horas tentando exatamente esse caso de uso e agora descobrindo que é impossível.
Por que não adicionar algo como "sinalizador de arquivo" à declaração de volume, considerando que podemos especificar opções de montagem adicionais como :ro e :rw ?

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

Quando estou mapeando o arquivo contêiner para o arquivo host, espero que o arquivo host seja criado (copiado do contêiner) na inicialização do contêiner.
Infelizmente, é bastante comum encontrar contêineres com arquivos de configuração colocados diretamente no diretório raiz do aplicativo e, obviamente, você não quer "aumentar o volume" da raiz inteira. Nesse caso, seria especialmente útil se estivesse funcionando.

@malyzeli você pode querer olhar para os segredos como uma forma de injetar configurações como esta, ou modelagem na inicialização.
Os volumes são realmente projetados para persistência, não configuração.
Na verdade, o docker não deve criar caminhos de host automaticamente, e esse comportamento foi removido nas APIs mais recentes.

@ cpuguy83

Não entendi seu ponto, então explique ou corrija minhas suposições, porque sou muito novo no ecossistema Docker.

Você pode querer olhar para os segredos como uma forma de injetar configurações como esta, ou modelagem na inicialização.

E se eu não souber como o arquivo de configuração ficará, porque ele foi criado por algum assistente de instalação diretamente do aplicativo (e que eventualmente muda de versão para versão)?
Muitos aplicativos têm esse tipo de configuração inicial, por exemplo, Limesurvey e NodeBB.

Os volumes são realmente projetados para persistência, não configuração.

Você está sugerindo que a configuração do contêiner existente não deve ser persistente?
E se eu quiser fazer backup de alguma parte da minha infraestrutura de vários contêineres?
Quero ter os dados e a configuração em volumes para que possa restaurá-los rapidamente se algo de errado acontecer.

Na verdade, o docker não deve criar caminhos de host automaticamente, e esse comportamento foi removido nas APIs mais recentes.

Na verdade, não preciso criar caminhos de host, mas inicializar determinado volume com dados de imagem existentes (por exemplo, "externalizar" alguns modelos html, que quero que sejam editáveis ​​do sistema host e / ou outro contêiner), e ainda funciona exatamente como indicado na referência do Dockerfile :

O comando docker run inicializa o volume recém-criado com todos os dados existentes no local especificado na imagem base.

E se eu não souber como o arquivo de configuração ficará, porque ele foi criado por algum assistente de instalação diretamente do aplicativo (e que eventualmente muda de versão para versão)?

Deixe-o ser criado, extraia-o da imagem / contêiner, faça disso um segredo

Quero ter os dados e a configuração em volumes para que possa restaurá-los rapidamente se algo de errado acontecer.

Use segredos. Também estamos examinando um objeto config dedicado que é semelhante aos segredos, mas não tão restrito ... mas hoje os segredos estão disponíveis.

Na verdade, eu não preciso disso para criar caminhos de host, mas para inicializar determinado volume com dados de imagem existentes (por exemplo, "externalizar" alguns modelos de html, que desejo que sejam editáveis ​​do sistema host e / ou outro contêiner), e ainda funciona exatamente como indicado na referência do Dockerfile:

As montagens Bind não são volumes. A referência do Dockerfile está falando sobre volumes. É uma pena que docker run -v seja usado para ambos.

Definitivamente, não estou dizendo para não usar volumes para armazenar configuração, estou dizendo que você deve avaliar se há uma solução melhor (e segredos da IMO são muito melhores para isso).

Os vínculos de host são uma solução ruim para qualquer coisa além de pegar algo que já existe no host e colocá-lo no contêiner ... e mesmo assim, geralmente não funciona quando você está falando sobre ambientes em cluster.

@ cpuguy83

Deixe-o ser criado, extraia-o da imagem / contêiner, faça disso um segredo

Sim, é o que eu faço, mas parece irritantemente complicado de qualquer maneira .. :-)

Use segredos. Também estamos examinando um objeto config dedicado que é semelhante aos segredos, mas não tão restrito ... mas hoje os segredos estão disponíveis.

Vou averiguar, não sabia sobre segredos, obrigado!

As montagens Bind não são volumes. A referência do Dockerfile está falando sobre volumes. É uma pena que docker run -v seja usado para ambos.

Ok, isso parece ser uma explicação de por que não funcionou como eu esperava. Eu pensei que binds e volumes são apenas nomes diferentes para a mesma coisa, considerando que é feito através do mesmo -v param.

Para quem vê esse bug no Windows ... mesmo que você tenha drives compartilhados ...

Há um problema em que, se você usar o Docker Windows (com docker-compose) e usar certas credenciais para "Compartilhar unidade", como C: \ ou D: \ etc., poderá ser necessário cancelar o compartilhamento, compartilhar a unidade novamente e entrar novamente credenciais, caso contrário, ele apresenta um erro relacionado como:

"ERROR: for ... Não é possível iniciar o serviço yourservice: oci runtime error: container_linux.go: 262: iniciando processo de contêiner causado" process_linux.go: 339: contêiner "causado \" rootfs_linux.go: 57: montagem \

"\\" causou \\ "não é um diretório \\" ""
: Você está tentando montar um diretório em um arquivo (ou vice-versa)? Verifique se o caminho do host especificado existe e é do tipo esperado "

BaranOrnarli como ser aquele que tem DockerToolbox?

O mesmo problema aqui, como a maioria das pessoas aqui. Mas consegui voltar a funcionar simplesmente reiniciando a VM.

Windows 10 Education
Docker Toolbox, 17.10.0-ce
VirtualBox 5.2.2

Executar isso via docker CLI funciona:
docker run -d -p 8080:80 -v $(pwd)/src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf tutorial / nginx

Executando o mesmo via docker-compose, não:
recorte
volumes: - ./src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf
Isto é, até eu desligar a VM por meio da GUI do VirtualBox e iniciar o Terminal de início rápido do Docker novamente.

Desde então, destruir repetidamente os contêineres e o docker-compose não gerava erro.

Espero que isso ajude alguém.

Eu tenho o mesmo problema. Enquanto isso, estou usando a pasta docker de volumes reais em docker-compose.yml. Esta é /var/lib/docker/volumes..../file.ext como uma solução temporária
(Docker versão 17.12.0-ce, compilação c97c6d6)

Se você tiver esse problema, verifique também se compartilhou seu diretório no Windows.

Estou no Ubuntu 14.04. Quando executo o comando docker-compose up -d , recebo o seguinte erro:

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

Estou usando o caminho absoluto para mapear o volume /home/curso-docker/email-worker-compose/nginx/default.conf do meu host.

Alguém tem ideia desse problema?

@AzeredoGabriel para mim, fazer o que @BaranOrnarli mencionou antes funcionou como um encanto. Redefina as credenciais do seu drive compartilhado, compartilhe-o novamente e ele deve funcionar. Não tenho ideia por que de repente parou de funcionar em primeiro lugar, mas agora está de novo.

Alguma novidade sobre isso? Ainda parece impossível montar um único arquivo

@Karlheinzniebuhr Isso nunca foi um problema. O Docker permite montar arquivos em um contêiner, mas você não pode montar um arquivo em um diretório ou vice-versa.

Alguma novidade sobre isso? Ainda parece impossível montar um único arquivo

tente mapear o arquivo com o diretório existente. O Docker tenta criar um diretório sempre se não existir.

@ cpuguy83 Claro que é um problema. Não estamos tentando montar arquivos em um diretório. Estamos tentando montar um único arquivo criado pelo contêiner para o host como um arquivo.

Podemos reabrir este problema? Ainda não funciona em 2019. No Docker mais recente e no docker-compose em execução no Debian mais recente.

Você não pode montar do contêiner para o host, apenas da outra maneira.
Este é o mesmo comportamento para diretórios e arquivos.

Mesmo problema, usando docker 19.03.1 e docker-compose 1.24.1, ao tentar substituir um arquivo de configuração na imagem store/elastic/filebeat:7.3.0 com vinculação de volume em 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 tentei usar "configs", mas descobri que esse recurso é apenas para o swarm.
Estou tentando encontrar uma maneira de fornecer um arquivo de configuração para a imagem padrão sem criar um personalizado com arquivos de configuração do COPY.

O mesmo 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

Alguma chance de consertar isso?

Problema irritante.

Colegas, verifique a direção da montagem em docker-compose.
Tive os mesmos problemas até perceber que estava errado, deveria ser assim:

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