ええ、これは私を元に戻しています！

fig killとfig rmますか？ 私はそれがVolumesFrom Dockerバグであると疑っています： //github.com/docker/fig/issues/328#issuecomment -50926263

fig killとfig rmますか？ 私はそれがVolumesFrom Dockerバグであると疑っています： //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

記録のために、dockerバージョンの出力は同じですが、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

だから私が見つけることができる唯一の違いはカーネルバージョンです。 1つ目（機能しない）はVFSで、2つ目は私のコンピューターです。 それは何が起こっているのかを理解するのに役立ちますか？

うーん、汚染してすみません。 単純なタイプミス。 私がこれに捕まった最初の人ではないようです。

（タイプミスのために）ホスト側の存在しない場所で「-v」が呼び出されると、空のディレクトリと、必要に応じてすべての親ディレクトリが作成されます。 次に、この空のディレクトリをコンテナにマウントしようとし、ファイルがすでにターゲットの場所にある場合、このメッセージをスローします。

dockerがホスト側にディレクトリを作成することを許可されるべきではないと思います。 このスレッドを汚染しないように、以前のコメント（およびこれは？）を削除する必要がありますか？

2セントを追加します/このスレッドをバンプします。 docker-compose単一のファイルを追加できると非常に便利です。 今のところ、コンテナごとに個別のディレクトリが必要ですが、ほとんどのコンテナには1つまたは2つのファイルしかありません。 それらをすべて同じフォルダーに入れて、個別に参照するのは素晴らしいことです。

ボリュームの実行に関して、ある時点でバグがあったと思います。そこには、バインドマウントされたファイルが含まれていました。
今日はこれが問題になるとは思いません。

これは繰り返し発生する問題のようです。

@ md5のリファレンスやその他のコメントによると、次の条件下でこの動作を忠実に再現できます。

• CentOS 7
• Docker 1.5.0（yumパッケージdocker-1.5.0-28.el7.centos）
• docker-compose 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 ：

このコミットはDockerのリリースバージョンにはなく、masterに修正が加えられており、1.6RCシリーズの一部です。

@ cpuguy83これはバージョン1.5.0であり、

Docker version 1.5.0-dev, build fc0329b/1.5.0

これは、CentOS 7 yumリポジトリで利用できるようになった「公式」ビルドであり、開発リポジトリの調整はありません。

docker-composeこの動作を示し、 docker runが示さないのはなぜですか？ これはDockerのバグですか、それともdocker-composeですか？

さらに情報が必要な場合はお知らせください。

@dayglojesusはい、これは1.5.0-devはdocker1.5.0がカットされた後にビルドされました。
このバグは、リリースされたバージョンのdockerには存在しません。

@ cpuguy83なるほど。 奇妙なことに、このパッケージがどのようにしてレポに組み込まれたのだろうか？ どのyumパッケージがCentOS7の実際のDocker1.5.0リリースに関連しているのか知っていますか？

よくわかりません... ping @ lsm5

@dayglojesusなので、インストールしたのはRHELで再コンパイルされたhttp ：//wiki.centos.org/Cloud/Dockerを参照して

そこにあるrhelのものが気になる場合は、 https：//bugzilla.redhat.comでバグをください。 HTH

この問題のRHELチケットを提出しました。 https://bugzilla.redhat.com/show_bug.cgi?id=1209625
ありがとう、@ lsm5。

うーん、docker1.5を搭載したubuntu14.04ltsでも同じことがわかりました

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
• コードネーム：trusty
• dockerバージョン1.5

問題が発生している場合、特に+1は、OPの問題とはまったく関係がない可能性が高いため、役に立ちません。

実行しているDockerコマンド、期待するもの、実際に見ているものを含めてください。
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が所有するdirとして作成され、コンテナーは実行されず、〜/ .gitconfigをマウントできないことに関するメッセージで停止します（フルパスを使用）チルダの省略形ではなく、テキスト）

私が期待すること：dockerは現在のユーザーが所有する空のファイルとして〜/ .gitconfigを作成し、コンテナーを正常に起動するか、〜/ .gitconfigをまったく作成せずに適切なエラーメッセージで開始することを拒否する必要があります

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ここでの問題は、ファイルが必要であることを検出する方法がないことです（これについては前に説明しました）。
開始スクリプトでは、 docker runコマンドの前にtouch ~/.gitconfig追加することをお勧めします。

:-Dそれが私がやったことです。
次に、ルート2を使用して、フォルダーを作成しないのはどうですか？

@gggeekその船は出航しており、残念ながら大きな変化となるでしょう。

;-（ しかたがない

Docker version 1.6.0, build 4749651このバグがあります

関連する問題： https ：

この問題の解決に関連することが1つ見つかったと思います。 AWSで最新のdocker-compose（1.20）/ docker（1.6.0）を使用しています。 そして、nginxを起動しようとするたびにこのエラーが発生していました：

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

必死になって、nginx Dockerfileを調べたところ、1つのボリュームが公開されていることがわかりました。 そこで、このボリュームをマウントしたリストに追加すると、突然すべてが機能しました。

したがって、docker-composeとdockerの継ぎ目の違いは、ボリュームのデフォルト値です。

問題は解決されましたが、解決策は何ですか？
Dockerコンテナにファイルをマウントできないのと同じ問題があります。
Windows上の最新のDockerToolboxバージョン（docker 1.9）
コンテナを開始すると、

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

Sascha-Egeriaと同じ、解決策？

報告している問題は、この問題と同じではありません。 この問題は、以前のバージョンのDockerのバグであり、かなり前に修正されました。

あなたの問題は＃2268に関連しているように聞こえますか？ あなたは完全な出力にその問題に投稿できる場合はdocker-compose version 、 docker info 、あなたの内容docker-compose.yml 、そしてあなたが走ったコマンド、我々はさらに、デバッグすることができるかもしれません問題。

最終的に、GitBashとコマンド「docker-machinessh [MACHINE]」を使用して問題を解決し、Dockerを操作します。
Windows上のDockerクイックスタートターミナル（1.9d）の新しいシェルは本当にうまく機能しません。

私は同じ問題を抱えています。
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ディレクトリを取得している場合、ファイルが見つかりませんでした。

ファイル/etc/server.confがイメージに存在するserver.conf:/etc/server.confでマウントしようとするdocker1.9.1で再現されました。

相対パスを使用すると、dockerはホストファイルをフォルダーの名前と見なすようになります。 これはコンテナ内のファイルであり、既存のファイル/etc/server.confにフォルダをマウントできないため、失敗します。

絶対パスを使用してserver.conf私のための修正に問題がdocker run -v /absolute/path/to/server.conf:/etc/server.conf ...し、ドッキングウィンドウの扱いserver.confいつものファイルとして。

相対パスは.で始まる必要があるため、 ./server.config試してください。

それがないと、名前付きボリュームと見なされます。

同じ問題があり、 .でもファイルをマウントできません。 Docker（またはdocker-compose？）は、絶対ファイルパスを指定しない限り、ファイルをフォルダーと見なします。

Docker：1.9.1
Docker-compose：1.5.2

docker-composeの動作で./server.conf:/etc/server.confを使用します。 ただし、docker CLIの-vオプションは、不正なパスについて文句を言い、マウントするファイルへの絶対パスのみを受け入れます。

@kirisetsz正解; docker-composeは相対パス（ docker-compose.ymlファイルに相対パス）を受け入れます。 Composeは、相対パスから絶対パスへの変換を処理します。 docker（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をファイルではなくディレクトリとしてマウントします

ウィンドウズ10
dockerバージョン：1.10.1
docker-バージョン1.6.0を作成し、cdb920aをビルドします

このバグは解決せずに閉じられたので、再開できますか？ それはまだ起こっています。 私の場合は他の多くの場合と同じで、nginx.confファイルを/etc/nginx/nginx.confの下のnginxイメージにマウントしようとしています。

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

VMware Fusionプラグイン（VMware Fusion 8.1.0）とCoreOSホストを備えたVagrantVMを使用してOSX（10.11.3）でDockerを実行しています。 関連するバージョン情報：

$ 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 ：

エラーは同じように見える場合がありますが、別の問題が原因である可能性があります。

https://github.com/docker/docker/issues/13670およびhttps://github.com/docker/docker/issues/19304も参照して

設定したworkdirがディレクトリとして存在しない場合にこれを取得できるという報告も聞いています。 あなたはこれらの問題の1つにぶつかっていると思います。

https://github.com/brikis98/docker-osx-devを使用してみて

この問題が発生し、髪の毛をすべて抜いた後、そのフォルダーがルート所有フォルダーへのシンボリックリンクであることがわかりました。

すべてのコンテンツを（私の）ユーザー所有のフォルダーに移動し、正常に動作します。

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

Google経由でこのスレッドを見つけました。 私もこの問題を抱えています。 単一のファイル、OSXにバインドできません。

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

Dockerは本日更新されました。

更新：ファイルではなくディレクトリとしてマウントしようとしていることを示すスクリーンショット。

私は同じ問題を抱えています:-(単一のファイルをマウントできません

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バインドしようとしているファイルまたはディレクトリが存在しない場合、dockerは_file_または_directory_のどちらを期待しているかを判断する方法がありません。その場合（ /usr/src/app/app.confが存在しない場合）存在する場合）、dockerデーモンはその場所にディレクトリを作成し、それをコンテナにバインドマウントします。

パスの自動作成を非推奨/削除しようとしましたが（代わりにエラーが発生しました）、これは後方互換性のない変更であるため（一部の人々はこの動作に依存しています）、この動作を維持する必要がありました。

@thaJeztah迅速な返信ありがとうございます！
docker-composeを起動する前に、手動でファイル「/usr/src/app/app.conf」を作成しようとしましたが、結果は次のとおりです。

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構成を方程式から外そうとすると、次のように再現できますか。

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テスト目的で提供してくれる場合は、

@boguleanは正しいので、

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 、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のバグのようで、DockerComposeとは関係ありません。
この場合、Dockerがディレクトリを作成する理由がわかりません。

何か案は？ どうもありがとう！

高山の画像であなたの例も試してみました。 同じ。 cat: read error: Is a directory

@thasmo filebeat.ymlはディレクトリであり、ファイルではないため、このエラーが発生します。
ファイルをコンテナにマウントする前に、ファイルがホストに存在することを確認する必要があります。存在しない場合、dockerがディレクトリを作成します。

@ cpuguy83 、私はちょうど問題を見つけたと思います。 Docker MachineとVirtualBoxを介してWindowsでDockerを使用していますが、VirtualBoxを介してローカルファイルをコンテナーにマウントできない可能性があります。
https://docs.docker.com/docker-for-windows/troubleshoot/#/host -filesystem-sharing

私は、Windows10アニバーサリーアップデートのクリーンインストールDockerでその問題を発見しました。
実際、この問題は非常に単純な解決策です

Dockerオプションでドライブを共有する必要がありますhttp://www.awesomescreenshot.com/image/1510321/0f1a81d7a8883df5a61bcdf04b3994cf
見た目は問題を見つけて解決します。

まだubuntu16.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のように存在しないファイルにマウントするようにdocker runを変更した場合、それは機能しますが、ディレクトリをマウントします。

@djpateは、同じホスト上で実行されている/home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.confが存在しない場合、デーモンはその名前で_directory_を作成し、コンテナー内の/etc/resolv.confにバインドマウントしようとします。 /etc/resolv.confは_file_であるため、ファイルの上にディレクトリをバインドマウントすると失敗します。

そうは言っても、ローカルファイルで/etc/resolv.confをオーバーライドすることは強くお勧めしません。 /etc/resolv.confは、使用する正しいDNSサーバーを設定するためにdockerによって管理されます。 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は初めてですが、自分のマシンで実行されていると思います。 私は基本的にdocker-engineとdocker-machineを通常のubuntuローカルマシンにインストールしました。 これは私の会社の開発環境であり、MacDockerのすべての人に役立つようです。

あなたが言ったように私はそれをDNSオプションに変更します、私はこれに気づいていませんでした。 ありがとうございました！ しかし、バグはまだ残っていると思います。

これは、docker-composev1.6.2とdockerv1.10.2でも機能しません:(

絶対パスの使用は機能しますが、残念ながら私のユースケースでは絶対パスは絶対に機能しません:(。考えられる./と../すべての組み合わせを試しました。

編集：また、私はVMのないLinuxで実行しているので、 @ thaJeztahソリューションは私には機能しません

OSはUbuntu14.04です

Dockerは現在1.13.1までです。 Dockerをアップグレードしてください。 1.12.x以降は機能しています。

ああ、ありがとう。 Dockerをアップグレードし、修正された場合は更新します:)

編集：働いた！ ありがとう@guice

@thaJeztah

バインドしようとしているファイルまたはディレクトリが存在しない場合、dockerは、ファイルまたはディレクトリを期待しているかどうかを判断する方法がありません。その場合（/usr/src/app/app.confが存在しない場合） '存在しない）、dockerデーモンはその場所にディレクトリを作成し、それをコンテナにバインドマウントします。
パスの自動作成を非推奨/削除しようとしましたが（代わりにエラーが発生しました）、これは後方互換性のない変更であるため（一部の人々はこの動作に依存しています）、この動作を維持する必要がありました。

このユースケースを正確に6時間試した後、それが不可能であることがわかった後、私は非常にイライラしています。
:roや:rwなどの追加のマウントオプションを指定できることを考慮して、ボリューム宣言に「ファイルフラグ」などを追加してみませんか？

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

コンテナファイルをホストファイルにマッピングする場合、コンテナの初期化時にホストファイルが作成（コンテナからコピー）されることを期待しています。
残念ながら、構成ファイルがアプリケーションのルートディレクトリに直接配置されているコンテナを見つけることは非常に一般的であり、ルート全体を「ボリューム化」したくないことは明らかです。 その場合、これが機能していれば特に役立ちます。

@malyzeliは、このような構成を挿入する方法として、または起動時にテンプレートを作成する方法として、シークレットを確認することをお勧めします。
ボリュームは、構成ではなく永続性のために実際に設計されています。
実際、dockerはホストパスを自動作成するべきではなく、この動作は新しいAPIでは削除されました。

@ cpuguy83

私はあなたの主張を理解していません。私はDockerエコシステムにまったく慣れていないので、私の仮定を説明または修正してください。

このような構成を挿入する方法として、または起動時にテンプレートを作成する方法として、シークレットを確認することをお勧めします。

構成ファイルがアプリケーションから直接インストールウィザードによって作成されたため（最終的にバージョンごとに変更されるため）、構成ファイルがどのように表示されるかわからない場合はどうなりますか？
LimesurveyやNodeBBなど、多くのアプリケーションにはこの種の初回セットアップがあります。

ボリュームは、構成ではなく永続性のために実際に設計されています。

既存のコンテナーの構成が永続的であってはならないことを意味していますか？
次に、マルチコンテナインフラストラクチャの一部をバックアップしたい場合はどうすればよいですか？
データと構成の両方をボリュームに入れて、何か問題が発生した場合にすばやく復元できるようにしたい。

実際、dockerはホストパスを自動作成するべきではなく、この動作は新しいAPIでは削除されました。

実際には、ホストパスを作成するためにそれは必要ありませんが、既存の画像データで特定のボリュームを初期化するために（たとえば、ホストシステムや他のコンテナから編集できるようにしたいいくつかのhtmlテンプレートを「外部化」する）、それでもDockerfileリファレンスに記載されているとおりに

docker runコマンドは、新しく作成されたボリュームを、ベースイメージ内の指定された場所に存在するデータで初期化します。

構成ファイルがアプリケーションから直接インストールウィザードによって作成されたため（最終的にバージョンごとに変更されるため）、構成ファイルがどのように表示されるかわからない場合はどうなりますか？

それを作成し、画像/コンテナから抽出し、秘密にします

データと構成の両方をボリュームに入れて、何か問題が発生した場合にすばやく復元できるようにしたい。

シークレットを使用します。 シークレットに似た専用のconfigオブジェクトも検討していますが、それほど制限されていません...しかし、今日はシークレットが利用可能です。

実際には、ホストパスを作成するためにそれは必要ありませんが、既存の画像データで特定のボリュームを初期化するために（たとえば、ホストシステムや他のコンテナから編集できるようにしたいいくつかのhtmlテンプレートを「外部化」する）、それでもDockerfileリファレンスに記載されているとおりに機能します。

バインドマウントはボリュームではありません。 Dockerfileリファレンスはボリュームについて話している。 docker run -vが両方に使用されているのは残念です。

構成の保存にボリュームを使用しないと言っているのではありません。より良い解決策があるかどうかを評価する必要があると言っています（IMOシークレットの方がはるかに優れています）。

ホストバインドは、ホスト上に既存のものを取得してコンテナーに取り込む以外の場合には悪い解決策です...それでも、クラスター化された環境について話している場合は、通常は機能しません。

@ cpuguy83

それを作成し、画像/コンテナから抽出し、秘密にします

ええ、それは私がしていることですが、とにかく面倒に複雑に見えます.. :-)

シークレットを使用します。 シークレットに似た専用のconfigオブジェクトも検討していますが、それほど制限されていません...しかし、今日はシークレットが利用可能です。

私はそれを調べます、秘密について知りませんでした、ありがとう！

バインドマウントはボリュームではありません。 Dockerfileリファレンスはボリュームについて話している。 docker run -vが両方に使用されているのは残念です。

さて、それは私が期待したように機能しなかった理由の説明のようです。 バインドとボリュームは、同じ-vパラメーターを介して行われることを考えると、同じものの名前が異なるだけだと思いました。

ドライブを共有している場合でも、 Windowsでこのバグを目​​にした人のために...

Docker Windows（docker-composeを使用）を使用し、C：\やD：\などの特定の資格情報を使用して「ドライブを共有」する場合、共有を解除し、ドライブを再度共有し、再入力する必要があるという問題があります。それ以外の場合は、次のようなエラーが発生します。

"エラー：for ...サービスを開始できませんyourservice：ociランタイムエラー：container_linux.go：262：コンテナプロセスを開始すると" process_linux.go：339：コンテナ "が発生しました\" rootfs_linux.go：57：mounting \

"\\"により\\ "ディレクトリではありません\\" ""
：ディレクトリをファイルにマウントしようとしていますか（またはその逆）？ 指定されたホストパスが存在し、予期されるタイプであるかどうかを確認してください。」

BaranOrnarli DockerToolboxを持っている人になる方法は？

ここにいるほとんどの人と同じ問題がここにあります。 しかし、VMを再起動するだけで再び機能するようになりました。

Windows10教育
Docker Toolbox、17.10.0-ce
VirtualBox 5.2.2

dockerCLIを介してこれを実行すると機能します。
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 GUIを介してVMをシャットダウンし、Dockerクイックスタートターミナルを再起動するまでです。

それ以来、コンテナとdocker-compose upを繰り返し破棄しても、エラーは再発しませんでした。

これが誰かを助けることを願っています。

私は同じ問題を抱えています。 それまでの間、docker-compose.ymlの実ボリュームdockerフォルダーを使用しています。 これは一時的な回避策として/var/lib/docker/volumes..../file.extです。
（Dockerバージョン17.12.0-ce、ビルドc97c6d6）

このような問題が発生した場合は、Windowsでディレクトリを共有しているかどうかも確認してください。

Ubuntu14.04のIm。 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-compose.ymlのボリュームバインディングを使用してstore/elastic/filebeat:7.3.0イメージの構成ファイルをオーバーライドしようとしているときにdocker-compose1.24.1を使用します。

    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

最初は「configs」を使用してみましたが、この機能は群れ専用であることがわかりました。
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
...