Compose: Bind Mount (Volumes) für Dateien nicht zulässig - nur für Directorys

Erstellt am 19. Aug. 2014  ·  94Kommentare  ·  Quelle: docker/compose

Hallo,
Beim Versuch, eine einzelne Datei (anstelle eines Verzeichnisses) bereitzustellen, wird ein Fehler ausgegeben:
Kann nicht Behälter bc0f924401841f2ed92c088cb8089cadad2359126b9f6a3ff15b6cb657835fb0 starten: setup /etc/eb8/freeIPA/server/etc/krb5.conf in /var/lib/docker/btrfs/subvolumes/bc0f924401841f2ed92c088cb8089cadad2359126b9f6a3ff15b6cb657835fb0/etc/krb5.conf Namespace binden Halterungen montieren Montage kein Verzeichnis

es ist im Docker erlaubt !!!

fig.yml

`` `Server:
Build: Docker-Freeipa
Häfen:
- 2222: 22
- "53"
- "80:80"
- 443: 443
- 389: 389
- 636: 636
- 88:88
- 464: 464
- 123: 123

environment:
    PASSWORD:   **************
    FORWARDER:  192.168.***.***

hostname:     freeipa
domainname:   ****.*****

privileged:   true

volumes:
    - /etc/eb8/freeIPA/server/etc/httpd/conf.d/:/etc/httpd/conf.d
    - /etc/eb8/freeIPA/server/etc/httpd/conf/:/etc/httpd/conf
    - /etc/eb8/freeIPA/server/etc/ipa/:/etc/ipa
    - /etc/eb8/freeIPA/server/etc/krb5.conf:/etc/krb5.conf
    - /etc/eb8/freeIPA/server/etc/pki-ca/:/etc/pki-ca
    - /etc/eb8/freeIPA/server/etc/ssh/:/etc/ssh
    - /etc/eb8/freeIPA/server/etc/sssd/:/etc/sssd
    - /etc/eb8/freeIPA/server/root/:/root
    - /etc/eb8/freeIPA/server/var/cache/ipa:/var/cache/ipa
    - /etc/eb8/freeIPA/server/var/lib/dirsrv/:/var/lib/dirsrv
    - /etc/eb8/freeIPA/server/var/lib/ipa-client/:/var/lib/ipa-client
    - /etc/eb8/freeIPA/server/var/lib/ipa/:/var/lib/ipa
    - /etc/eb8/freeIPA/server/var/log/:/var/log

`` `

arevolumes kinbug

Hilfreichster Kommentar

@ thaJeztah

Wenn die Datei oder das Verzeichnis, die bzw. das Sie binden möchten, nicht vorhanden ist, kann Docker in diesem Fall nicht feststellen, ob Sie eine Datei oder ein Verzeichnis erwarten (falls /usr/src/app/app.conf dies nicht tut) nicht vorhanden), erstellt der Docker-Daemon ein Verzeichnis an diesem Speicherort und bindet es im Container ein.
Beachten Sie, dass wir versucht haben, die automatische Erstellung des Pfads zu verwerfen / zu entfernen (und stattdessen einen Fehler zu erzeugen), dies jedoch zu sehr eine rückwärts inkompatible Änderung war (einige Leute verlassen sich auf dieses Verhalten), sodass wir dieses Verhalten beibehalten mussten.

Ich bin ziemlich frustriert, nachdem ich sechs Stunden lang genau diesen Anwendungsfall ausprobiert habe und jetzt herausgefunden habe, dass es unmöglich ist.
Warum nicht etwas wie "Dateiflagge" zur Datenträgerdeklaration hinzufügen, wenn man bedenkt, dass wir zusätzliche Einhängeoptionen wie :ro und :rw angeben können?

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

Wenn ich eine Containerdatei einer Hostdatei zuordne, erwarte ich, dass die Hostdatei bei der Containerinitialisierung erstellt (aus dem Container kopiert) wird.
Leider ist es durchaus üblich, Container zu finden, deren Konfigurationsdateien direkt im Anwendungsstammverzeichnis abgelegt werden, und natürlich möchten Sie nicht den gesamten Stamm "volumisieren". In diesem Fall wäre es besonders nützlich, wenn dies funktionieren würde.

Alle 94 Kommentare

Ja, das bringt mich zurück!

Funktioniert es, nachdem Sie fig kill und fig rm ? Ich habe den Verdacht, dass es sich um einen Docker-Fehler mit VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

Funktioniert es, nachdem Sie fig kill und fig rm ? Ich habe den Verdacht, dass es sich um einen Docker-Fehler mit VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

Nein nicht wirklich,

Gleicher Fehler hier beim Versuch, Volumes mit einer Datei zu verwenden ...

Funktioniert hier nicht mit einem 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

Aber es funktioniert gut auf meinem PC:

$ 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

Für die Datensätze ist die Ausgabe der Docker-Version dieselbe, aber ich bin mir ziemlich sicher, dass sie nicht so wichtig ist, da ich mich erinnere, dass sie auch in 1.2 perfekt funktioniert hat ...

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

Der einzige Unterschied, den ich erkennen kann, ist die Kernel-Version. Das erste (das funktioniert nicht) ist ein VFS, das zweite ist mein Computer. Hilft das zu verstehen, was passiert?

Humm, entschuldige die Verschmutzung. Einfacher Tippfehler. Es scheint nicht, dass ich der erste bin, der davon erwischt wird.

Wenn "-v" an einem nicht vorhandenen Speicherort auf der Hostseite aufgerufen wird (aufgrund eines Tippfehlers), werden ein leeres Verzeichnis und gegebenenfalls das gesamte übergeordnete Verzeichnis erstellt. Wenn dann versucht wird, dieses leere Verzeichnis auf dem Container bereitzustellen, und sich eine Datei bereits am Zielspeicherort befindet, wird diese Nachricht ausgegeben.

Ich denke nicht, dass Docker Verzeichnisse auf der Hostseite erstellen darf. Sollte ich meinen vorherigen Kommentar (und diesen?) Löschen, um eine Verschmutzung dieses Threads zu vermeiden?

Ich werde meine zwei Cent / Stoß diesen Thread hinzufügen. Es wäre sehr hilfreich, einzelne Dateien in docker-compose hinzufügen zu können. Im Moment muss ich für jeden meiner Container ein separates Verzeichnis haben, aber die meisten von ihnen enthalten nur 1 oder 2 Dateien. Es wäre großartig, sie alle in denselben Ordner zu legen und sie dann einzeln zu referenzieren.

Ich denke, irgendwann gab es einen Fehler beim Erstellen von Volumes, von denen bindmontierte Dateien enthielten.
Ich denke nicht, dass dies heute ein Problem ist.

Dies scheint ein wiederkehrendes Problem zu sein.

Gemäß der Referenz von

  • CentOS 7
  • Docker 1.5.0 (yum package docker-1.5.0-28.el7.centos)
  • Docker-Compose 1.1.0

Dieses Verhalten war im yum-Paket docker-1.5.0-1.el7 nicht vorhanden.

Beispiel:

Verwenden einer einfachen Serviceerklärung:

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

Beim Versuch, das Mounten einer Datei anstelle eines Verzeichnisses zu binden, erzeugt docker-compose Folgendes:

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

Der entsprechende Befehl docker run wird jedoch erfolgreich sein:

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

@dayglojesus Sie scheinen eine Entwicklungsversion von Docker zu verwenden.
Können Sie die Ausgabe von docker version bereitstellen?
Die Fehlermeldung, die Sie hier haben, stammt von diesem Commit: https://github.com/docker/docker/commit/b0ed2da4418d62d2d7b940b49e0e89bdcd264569

Dieses Commit ist nicht in einer veröffentlichten Version von Docker enthalten, hat einen Fix im Master und ist Teil der 1.6 RC-Serie.

@ cpuguy83 Es wird berichtet, dass dies Version 1.5.0 ist, nicht 1.6 RC:

Docker version 1.5.0-dev, build fc0329b/1.5.0

Dies ist der "offizielle" Build, der in den CentOS 7 Yum-Repos verfügbar ist, keine Verbesserungen für Entwickler-Repos.

Warum zeigt docker-compose dieses Verhalten und docker run nicht? Ist das ein Fehler in Docker oder docker-compose ?

Lassen Sie mich wissen, wenn Sie weitere Informationen benötigen.

@dayglojesus Ja, dies ist keine veröffentlichte Version von Docker. 1.5.0-dev wurde irgendwann nach dem Schneiden von Docker 1.5.0 erstellt.
Der Fehler ist in einer veröffentlichten Docker-Version nicht vorhanden.

@ cpuguy83 Ich

Ich bin nicht sicher ... ping @ lsm5

@dayglojesus Das von Ihnen installierte ist also der RHEL-neu kompilierte Docker, der einige Redhat-Patches über dem Upstream-Docker hat. Wenn Ihnen das egal ist und Sie nur eine Drehzahl mit Upstream-Docker wünschen, lesen Sie bitte: http://wiki.centos.org/Cloud/Docker . Dies erwähnt ein zusätzliches Repo, das eine Drehzahl enthält, die ich separat als Teil der CentOS virt SIG erstellt habe.

Wenn Sie sich für das Rhel-Zeug interessieren, melden Sie bitte einen Fehler unter https://bugzilla.redhat.com . HTH

Ein RHEL-Ticket für dieses Problem wurde eingereicht. https://bugzilla.redhat.com/show_bug.cgi?id=1209625
Danke, @ lsm5.

Mmm, habe das gleiche auf Ubuntu 14.04lts mit Docker 1.5

passiert mir unter Linux Mint / Ubuntu, die Dateien sind überhaupt nicht gemountet (sie sollen den Container überschreiben, aber sie tun es nicht)

Ich habe das gleiche Problem mit etc-localtime

  • Linux guest.vm 3.13.0-49-generic # 81-Ubuntu
  • x86_64 x86_64 x86_64 GNU / Linux
  • Beschreibung: Ubuntu 14.04.2 LTS
  • Veröffentlichung: 14.04
  • Codename: vertrauenswürdig
  • Docker Version 1.5

Wenn Sie ein Problem haben, helfen +1 nicht, zumal sie höchstwahrscheinlich überhaupt nicht mit dem Problem des OP zusammenhängen.

Bitte geben Sie an, welchen Docker-Befehl Sie ausführen, was Sie erwarten und was Sie tatsächlich sehen.
Schließen Sie auch die Ausgabe von docker info und docker version .
Vielen Dank.

@ cpuguy83 ok, hier ist über meinen Fall:

Befehl:

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

Situation: ~ / .gitconfig ist auf dem Host nicht vorhanden, bevor dieser Befehl ausgeführt wird

Was passiert: ~ / .gitconfig wird als Verzeichnis erstellt, das root gehört (anstelle des aktuellen Benutzers), und der Container wird nicht ausgeführt. Die Meldung wird angezeigt, dass ~ / .gitconfig nicht gemountet werden kann (unter Verwendung des vollständigen Pfads in seinem Verzeichnis) Text, nicht die Tilde-Kurzschrift)

Was ich erwartet habe: Entweder sollte Docker ~ / .gitconfig als leere Datei erstellen, die dem aktuellen Benutzer gehört, und den Container erfolgreich starten, oder sich weigern, mit einer besseren Fehlermeldung zu beginnen, ohne ~ / .gitconfig überhaupt erstellt zu haben

Docker-Info:

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 Das Problem hier ist, dass wir nicht erkennen können, dass Sie eine Datei möchten (dies wurde bereits zuvor besprochen).
In Ihrem Startskript würde ich empfehlen, vor Ihrem Befehl docker run ein touch ~/.gitconfig hinzuzufügen.

:-D das habe ich letztendlich getan.
Was ist dann mit Route 2 und nicht mit dem Erstellen des Ordners?

@gggeek Das Schiff ist gesegelt und wäre leider eine bahnbrechende Veränderung.

;-( Naja

Ich habe diesen Fehler mit Docker version 1.6.0, build 4749651

Ich glaube, ich habe eine Sache gefunden, die mit der Lösung dieses Problems zusammenhängt. Ich verwende das neueste Docker-Compose (1.20) / Docker (1.6.0) unter AWS. Und bekam diesen Fehler jedes Mal, wenn ich versuchte, nginx zu starten:

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

Aus Verzweiflung schaute ich in Nginx Dockerfile und stellte fest, dass es ein Volume freigibt. Also habe ich diesen Band zu der Liste hinzugefügt, die ich gemountet habe und plötzlich hat alles funktioniert!

Der Unterschied zwischen Docker-Compose- und Docker-Nähten ist also der Standardwert für Volumes.

Das Problem wurde geschlossen, aber was ist die Lösung?
Wir haben das gleiche Problem, dass wir keine Dateien in einen Docker-Container einbinden können.
Neueste Docker Toolbox-Version (Docker 1.9) unter Windows
Das Starten des Containers endet in

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

Wie Sascha-Egeria, eine Lösung?

Das Problem, das Sie melden, ist nicht dasselbe wie dieses Problem. Dieses Problem war ein Fehler in einer früheren Version von Docker, der vor langer Zeit behoben wurde.

Ihr Problem klingt vielleicht im Zusammenhang mit # 2268? Wenn Sie in dieser Ausgabe mit der vollständigen Ausgabe von docker-compose version , docker info , dem Inhalt Ihrer docker-compose.yml und den von Ihnen ausgeführten Befehlen posten könnten, könnten wir möglicherweise das Debuggen fortsetzen die Angelegenheit.

Ich löse mein Problem endlich mit Git Bash und dem Befehl "docker-machine ssh [MACHINE]", um mit Docker zu arbeiten.
Die neue Shell von Docker Quickstart Terminal (1.9d) unter Windows funktioniert wirklich schlecht.

Ich habe das gleiche Problem.
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 Wenn Sie ein Verzeichnis erhalten, konnte es die Datei nicht finden.

Wiedergabe in Docker 1.9.1, wobei versucht wird, mit server.conf:/etc/server.conf zu mounten, wobei die Datei /etc/server.conf in einem Bild vorhanden ist.

Die Verwendung eines relativen Pfads scheint Docker dazu zu bringen, die Hostdatei als Namen eines Ordners zu betrachten. Da es sich um eine Datei im Container handelt und wir keinen Ordner in die vorhandene Datei /etc/server.conf einbinden können, schlägt dies fehl.

Die Verwendung eines absoluten Pfads zu server.conf behebt das Problem für mich docker run -v /absolute/path/to/server.conf:/etc/server.conf ... und Docker behandelt server.conf wie eine normale Datei.

Relative Pfade müssen mit einem . . Versuchen Sie es also mit ./server.config .

Ohne es wird es als benanntes Volume betrachtet.

Ich habe das gleiche Problem und kann die Datei auch mit einem . nicht mounten. Docker (oder Docker-Compose?) Betrachtet die Datei als Ordner, es sei denn, ich gebe einen absoluten Dateipfad an.

Docker: 1.9.1
Docker-Compose: 1.5.2

Verwenden Sie ./server.conf:/etc/server.conf für Docker-Compose-Werke. Die Option -v Docker CLI beschwert sich jedoch über einen unzulässigen Pfad und akzeptiert nur den absoluten Pfad zu der Datei, die gemountet werden soll.

@ kirisetsz richtig; Docker-Compose akzeptiert relative Pfade (die relativ zur Datei docker-compose.yml ). Compose kümmert sich um die Umwandlung eines relativen Pfades in einen absoluten Pfad. Wenn Sie Docker verwenden (nicht komponieren), müssen Sie einen absoluten Pfad angeben. Sie können -v $(pwd)/server.conf:/etc/server.conf wenn Sie nicht den gesamten Pfad eingeben möchten

Ich bestätige, ich habe das gleiche Problem mit:
Mac OS X.10.11.3
Docker version 1.9.1, build a34a1d5
docker-compose version 1.5.2, build 7240ff3
Selbst wenn ich einen absoluten oder einen relativen Hostpfad spezifiziere, habe ich die gleiche Antwort:
ERROR: Cannot start container a9ed08a3ee639f61ff2720745011c940a5fff5b9b98bda6a45156a80381c5328: [8] System error: not a directory
Zu Ihrer Information:

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

Ich habe auch dieses Problem

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

In diesem Beispiel wird auth.json als Verzeichnis auf dem Hostcomputer erstellt und sollte eine Datei sein. Wenn ich auth.json zum ersten Mal auf dem Host-Computer platziere, beschwert es sich, dass es sich nicht um ein Verzeichnis handelt.

Für mich auch, wenn ich versuche:

Bände:
- ./docker/default.conf:/etc/nginx/conf.d/default.conf

Ich erhalte die Fehlermeldung: FEHLER: Container 9f kann nicht gestartet werden ...... f1e: [9] Systemfehler: kein Verzeichnis

Wenn ich conf.d in etwas anderes ändere, funktioniert es, aber es mounten default.conf als Verzeichnis anstelle von Datei

Windows 10
Docker-Version: 1.10.1
Docker-Compose Version 1.6.0, Build CDB920a

Kann dieser Fehler bitte erneut geöffnet werden, da er ohne Lösung geschlossen wurde? Es passiert immer noch. Mein Fall ist der gleiche wie bei vielen anderen, bei dem versucht wird, eine nginx.conf-Datei in das nginx-Image unter /etc/nginx/nginx.conf einzubinden.

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

Ausgabe:

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

Ich verwende Docker unter OS X (10.11.3) mit einer Vagrant-VM mit dem VMware Fusion-Plugin (VMware Fusion 8.1.0) und einem CoreOS-Host. Relevante Versionsinformationen:

$ 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

Bitte lesen Sie meinen Kommentar hier: https://github.com/docker/compose/issues/424#issuecomment -157751229

Der Fehler mag gleich aussehen, wird aber höchstwahrscheinlich durch ein anderes Problem verursacht.

Siehe auch https://github.com/docker/docker/issues/13670 und https://github.com/docker/docker/issues/19304.

Ich habe auch Berichte gehört, dass Sie dies erhalten können, wenn das von Ihnen festgelegte Arbeitsverzeichnis nicht als Verzeichnis existiert. Ich glaube, Sie treffen eines dieser Probleme.

Ich bin auf dieses Problem gestoßen und habe nach dem Herausziehen aller Haare festgestellt, dass der Ordner ein Symlink zu einem Ordner im Stammverzeichnis ist.

Alle Inhalte wurden in (meinen) benutzereigenen Ordner verschoben und funktionieren einwandfrei.

Docker-1.12.0-rc2
Docker-Maschine 0.8.0-rc1
Docker-Compose 1.8.0-rc1

Fand diesen Thread über Google. Ich habe auch dieses Problem. Ich kann nicht an einzelne Dateien binden, OSX.

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

Docker wurde gerade heute aktualisiert.

Update: Screenshot zeigt den Versuch, als Verzeichnis und nicht als Datei zu mounten.

screen shot 2016-07-19 at 5 25 35 pm

Ich habe das gleiche Problem :-( kann keine einzelne Datei mounten

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

Bestätigung des Problems

Das heutige Update unter OSX hat das Problem behoben. Ich konnte eine einzelne Datei mit Docker-Compose erfolgreich bereitstellen.

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

Es wurde versucht, eine Datei mit Docker-Compose bereitzustellen

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

Auf dem Host-Computer

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 hat ein Verzeichnis erstellt: drwxr-xr-x app.conf
anstelle einer Datei.

Ist das ein normales Verhalten? Ich nahm an, dass die Datei erstellt und gemountet werden sollte.

Ich werde sehr dankbar sein, wenn mir jemand eine Klarstellung gibt.

# 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 Wenn die Datei oder das Verzeichnis, die bzw. das Sie binden möchten, nicht vorhanden ist, kann Docker in diesem Fall nicht feststellen, ob Sie eine _Datei_ oder ein _Verzeichnis_ erwarten (falls /usr/src/app/app.conf nicht exist) erstellt der Docker-Daemon ein Verzeichnis an diesem Speicherort und bindet es im Container ein.

Beachten Sie, dass wir versucht haben, die automatische Erstellung des Pfads zu verwerfen / zu entfernen (und stattdessen einen Fehler zu erzeugen), dies jedoch zu sehr eine rückwärts inkompatible Änderung war (einige Leute verlassen sich auf dieses Verhalten), sodass wir dieses Verhalten beibehalten mussten.

@thaJeztah Danke für die schnelle Antwort!
Ich habe versucht, eine Datei "/usr/src/app/app.conf" manuell zu erstellen, bevor ich Docker-Compose gestartet habe. Das Ergebnis ist unten aufgeführt:

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 Was ist dein Setup? Laufen sowohl der Daemon als auch der Client auf demselben Computer oder arbeiten Sie mit einem Remote-Daemon (oder einem Daemon, der in einer virtuellen Maschine ausgeführt wird?)

@thaJeztah Ich benutze DO Host, Ubuntu 16.04 LTS,
Docker-Compose und Docker darauf installiert, finden Sie Versionen unten:

# 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

Auf diesem Computer läuft alles, bis ich mit ssh verbunden bin

Wenn Sie versuchen, Docker Compose aus der Gleichung herauszunehmen, können Sie versuchen, mit zu reproduzieren.

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

Das sollte die Konfigurationsdatei binden und ihren Inhalt drucken

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 Ich könnte auch docker-compose.yml ausführen, wenn Sie es mir zu Testzwecken geben

@bogulean richtig, erstellen / ausführen . Dies wäre das Äquivalent zum vorherigen Test, aber dann durch Docker-Compose;

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

Und um zu versuchen, ob es funktioniert;

docker-compose run web

(was auch Hello from /usr/src/app/app.conf drucken sollte)

@thaJeztah , vielen Dank! Ihre docker-compose.yml hat Hello from /usr/src/app/app.conf
Dadurch wurde mir klar, dass ich an einem anderen Ort etwas falsch mache, und ich stellte fest, dass meine Docker-Datei eine Zeile enthält:
VOLUME ["/usr/src/app.conf"]
entfernte es und die Datei begann wie erwartet zu binden.

Vielen Dank für Ihre Zeit.

Gut zu hören und gerne helfen!

Das Problem in Ihrem Fall ist, dass VOLUME auch ein Verzeichnis erwartet, also ein Volume erstellt und versucht hat, dieses bei /usr/src/app.conf zu mounten. Der beste Weg, um mit einzelnen Dateien vom Host zu arbeiten, besteht normalerweise darin, diese Situation zu berücksichtigen, indem Sie beispielsweise ein Verzeichnis /usr/src/config/ . Sie würden dann anstelle der Datei für dieses Verzeichnis bind-mount (oder ein Volume verwenden). Offensichtlich nicht immer möglich

@thaJeztah , ich habe das gleiche Problem beim Ausführen dieses:

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

/ existiert definitiv im Bild / Container:

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

Scheint im Allgemeinen ein Docker-Fehler zu sein, der nicht mit Docker Compose zusammenhängt.
Ich bin mir nicht sicher, warum Docker in diesem Fall ein Verzeichnis erstellen würde.

Irgendwelche Ideen? Vielen Dank!

Ich habe auch Ihr Beispiel mit dem Alpenbild ausprobiert. Gleich. cat: read error: Is a directory

@thasmo Sie erhalten diesen Fehler, weil filebeat.yml ein Verzeichnis ist, keine Datei.
Sie müssen sicherstellen, dass die Datei auf dem Host vorhanden ist, bevor Sie versuchen, sie in den Container einzubinden. Andernfalls erstellt Docker ein Verzeichnis für Sie.

@ cpuguy83 , ich glaube ich habe gerade das Problem gefunden. Ich verwende Docker unter Windows über Docker Machine und VirtualBox und kann die lokale Datei wahrscheinlich nicht über VirtualBox in den Container einbinden.
https://docs.docker.com/docker-for-windows/troubleshoot/#/host -filesystem-shared

Ich habe dieses Problem bei der Neuinstallation von Docker unter Windows 10 Jubiläums-Update gefunden.
In der Tat ist dieses Problem eine sehr einfache Lösung

Benötigt gemeinsame Laufwerke in Docker-Optionen http://www.awesomescreenshot.com/image/1510321/0f1a81d7a8883df5a61bcdf04b3994cf
Looks finden und lösen Probleme.

Immer noch das Problem auf 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".

Wenn ich den Docker-Lauf so geändert habe, dass er in eine Datei eingehängt wird, die nicht wie / tmp / foo vorhanden ist, funktioniert er, stellt jedoch ein Verzeichnis bereit.

@djpate wird Ihr Docker-Daemon auf demselben Host ausgeführt (und nicht in einer virtuellen Maschine?). Wenn /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf auf dem Computer, auf dem der Docker-Daemon ausgeführt wird, nicht vorhanden ist, erstellt der Daemon ein Verzeichnis mit diesem Namen und versucht, es bei /etc/resolv.conf im Container zu binden. Da /etc/resolv.conf eine _Datei_ ist, schlägt das Binden eines Verzeichnisses über einer Datei fehl.

Trotzdem würde ich dringend davon abraten, /etc/resolv.conf mit einer lokalen Datei zu überschreiben. /etc/resolv.conf wird vom Docker verwaltet, um den richtigen DNS-Server für die Verwendung festzulegen. Docker verfügt über einen eingebetteten DNS-Server für die Diensterkennung. Wenn Sie diese Datei überschreiben, funktioniert die Diensterkennung nicht.

Wenn Sie DNS-Optionen festlegen möchten, verwenden Sie die Optionen --dns , --dns-opt und --dns-search für 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 [])

Dadurch werden diese Optionen festgelegt, ohne dass unerwartete Ergebnisse auftreten. Beachten Sie, dass der DNS im Container immer 127.0.0.11 (der eingebettete DNS-Server) ist, dieser Server jedoch automatisch Anforderungen an den DNS-Server weiterleitet, den Sie mit --dns

@thaJeztah Ich bin neu bei Docker, aber ich würde denken, dass es auf meinem Computer läuft. Grundsätzlich habe ich Docker-Engine und Docker-Maschine auf einem normalen lokalen Ubuntu-Computer installiert. Dies ist die Entwicklungsumgebung meines Unternehmens und scheint für alle auf einem Mac-Docker zu funktionieren.

Ich werde es in die DNS-Option ändern, wie Sie erwähnt haben. Ich war mir dessen nicht bewusst. Vielen Dank! Aber der Fehler ist immer noch da, denke ich.

Dies funktioniert auch bei Docker-Compose v1.6.2 und Docker v1.10.2 nicht :(

Die Verwendung von absoluten Pfaden funktioniert, aber leider funktionieren absolute Pfade für meinen Anwendungsfall absolut nicht :(. Ich habe jede Kombination von ./ und ../ ausprobiert, die mir einfällt.

EDIT: Außerdem laufe ich unter Linux ohne VMs, daher

Betriebssystem ist Ubuntu 14.04

Docker ist jetzt auf 1.13.1. Bitte aktualisieren Sie Ihren Docker. Es funktioniert seit 1.12.x.

Ah, Danke. Wird Docker aktualisieren und aktualisieren, wenn / wenn behoben :)

EDIT: Arbeitete! Danke @guice

@ thaJeztah

Wenn die Datei oder das Verzeichnis, die bzw. das Sie binden möchten, nicht vorhanden ist, kann Docker in diesem Fall nicht feststellen, ob Sie eine Datei oder ein Verzeichnis erwarten (falls /usr/src/app/app.conf dies nicht tut) nicht vorhanden), erstellt der Docker-Daemon ein Verzeichnis an diesem Speicherort und bindet es im Container ein.
Beachten Sie, dass wir versucht haben, die automatische Erstellung des Pfads zu verwerfen / zu entfernen (und stattdessen einen Fehler zu erzeugen), dies jedoch zu sehr eine rückwärts inkompatible Änderung war (einige Leute verlassen sich auf dieses Verhalten), sodass wir dieses Verhalten beibehalten mussten.

Ich bin ziemlich frustriert, nachdem ich sechs Stunden lang genau diesen Anwendungsfall ausprobiert habe und jetzt herausgefunden habe, dass es unmöglich ist.
Warum nicht etwas wie "Dateiflagge" zur Datenträgerdeklaration hinzufügen, wenn man bedenkt, dass wir zusätzliche Einhängeoptionen wie :ro und :rw angeben können?

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

Wenn ich eine Containerdatei einer Hostdatei zuordne, erwarte ich, dass die Hostdatei bei der Containerinitialisierung erstellt (aus dem Container kopiert) wird.
Leider ist es durchaus üblich, Container zu finden, deren Konfigurationsdateien direkt im Anwendungsstammverzeichnis abgelegt werden, und natürlich möchten Sie nicht den gesamten Stamm "volumisieren". In diesem Fall wäre es besonders nützlich, wenn dies funktionieren würde.

@malyzeli Vielleicht möchten Sie sich Geheimnisse ansehen, um eine Vorlagen zu erstellen .
Volumes sind wirklich auf Persistenz ausgelegt, nicht auf Konfiguration.
Wirklich Docker sollte überhaupt keine Host-Pfade automatisch erstellen, und dieses Verhalten wurde auf neueren APIs entfernt.

@ cpuguy83

Ich verstehe Ihren Standpunkt nicht, also erklären oder korrigieren Sie bitte meine Annahmen, da ich im Docker-Ökosystem ziemlich neu bin.

Vielleicht möchten Sie sich Geheimnisse ansehen, um eine solche Konfiguration einzufügen oder beim Start Vorlagen zu erstellen.

Was ist, wenn ich nicht weiß, wie die Konfigurationsdatei aussehen wird, weil sie von einem Installationsassistenten direkt aus der Anwendung erstellt wird (und sich schließlich von Version zu Version ändert)?
Viele Anwendungen haben diese Art der erstmaligen Einrichtung, zum Beispiel Limesurvey und NodeBB.

Volumes sind wirklich auf Persistenz ausgelegt, nicht auf Konfiguration.

Bedeuten Sie, dass die Konfiguration des vorhandenen Containers nicht dauerhaft sein sollte?
Was ist dann, wenn ich einen Teil meiner Multi-Container-Infrastruktur sichern möchte?
Ich möchte sowohl Daten als auch Konfiguration in Volumes haben, damit ich sie schnell wiederherstellen kann, wenn etwas nicht stimmt.

Wirklich Docker sollte überhaupt keine Host-Pfade automatisch erstellen, und dieses Verhalten wurde auf neueren APIs entfernt.

Eigentlich brauche ich es nicht, um Host-Pfade zu erstellen, sondern um ein bestimmtes Volume mit vorhandenen Image-Daten zu initialisieren (zum Beispiel einige HTML-Vorlagen, die ich vom Host-System und / oder einem anderen Container bearbeiten lassen möchte, "externalisieren"), und es bleibt funktioniert genau wie in der Dockerfile-Referenz angegeben :

Der Docker-Ausführungsbefehl initialisiert das neu erstellte Volume mit allen Daten, die an der angegebenen Position im Basis-Image vorhanden sind.

Was ist, wenn ich nicht weiß, wie die Konfigurationsdatei aussehen wird, weil sie von einem Installationsassistenten direkt aus der Anwendung erstellt wird (und sich schließlich von Version zu Version ändert)?

Lassen Sie es erstellen, extrahieren Sie es aus dem Bild / Container, machen Sie ein Geheimnis daraus

Ich möchte sowohl Daten als auch Konfiguration in Volumes haben, damit ich sie schnell wiederherstellen kann, wenn etwas nicht stimmt.

Verwenden Sie Geheimnisse. Wir betrachten auch ein dediziertes config -Objekt, das Geheimnissen ähnelt, nur nicht so eingeschränkt ist ... aber heute sind Geheimnisse verfügbar.

Eigentlich brauche ich es nicht, um Host-Pfade zu erstellen, sondern um ein bestimmtes Volume mit vorhandenen Image-Daten zu initialisieren (zum Beispiel einige HTML-Vorlagen, die ich vom Host-System und / oder einem anderen Container aus bearbeiten möchte, "externalisieren"), und es bleibt funktioniert genau wie in der Dockerfile-Referenz angegeben:

Bindungshalterungen sind keine Volumes. Die Dockerfile-Referenz spricht von Volumes. Es ist bedauerlich, dass docker run -v für beide verwendet wird.

Ich sage definitiv nicht, dass Sie keine Volumes zum Speichern der Konfiguration verwenden sollen. Ich sage, Sie sollten prüfen, ob es eine bessere Lösung gibt (und IMO-Geheimnisse sind dafür viel besser).

Hostbindungen sind eine schlechte Lösung für alles andere, als etwas, das bereits auf dem Host vorhanden ist, in den Container zu übernehmen ... und selbst dann ist es im Allgemeinen nicht funktionsfähig, wenn Sie über Clusterumgebungen sprechen.

@ cpuguy83

Lassen Sie es erstellen, extrahieren Sie es aus dem Bild / Container, machen Sie ein Geheimnis daraus

Ja, das ist was ich tue, aber es scheint trotzdem ärgerlich kompliziert zu sein .. :-)

Verwenden Sie Geheimnisse. Wir betrachten auch ein dediziertes config -Objekt, das Geheimnissen ähnelt, nur nicht so eingeschränkt ist ... aber heute sind Geheimnisse verfügbar.

Ich werde mich darum kümmern, wusste nichts über Geheimnisse, danke!

Bindungshalterungen sind keine Volumes. Die Dockerfile-Referenz spricht von Volumes. Es ist bedauerlich, dass docker run -v für beide verwendet wird.

Okay, das scheint eine Erklärung dafür zu sein, warum es nicht so funktioniert hat, wie ich es erwartet hatte. Ich dachte, dass Bindungen und Volumes nur unterschiedliche Namen für dasselbe Objekt haben, wenn man bedenkt, dass dies über denselben -v -Parameter erfolgt.

Für diejenigen, die diesen Fehler in Windows sehen ... auch wenn Sie Laufwerke freigegeben haben ...

Es gibt ein Problem, bei dem Sie, wenn Sie Docker Windows (mit Docker-Compose) verwenden und bestimmte Anmeldeinformationen zum "Freigeben von Laufwerken" wie C: \ oder D: \ usw. verwenden, möglicherweise die Freigabe aufheben, das Laufwerk erneut freigeben und erneut eingeben müssen Anmeldeinformationen, andernfalls erhalten Sie einen Fehler wie:

"FEHLER: für ... Dienst kann nicht gestartet werden Dienst: oci Laufzeitfehler: container_linux.go: 262: Start des Containerprozesses verursacht" process_linux.go: 339: container "verursacht \" rootfs_linux.go: 57: mounting \

"\\" verursacht \\ "kein Verzeichnis \\" ""
: Versuchen Sie, ein Verzeichnis in eine Datei einzubinden (oder umgekehrt)? Überprüfen Sie, ob der angegebene Hostpfad vorhanden ist und vom erwarteten Typ ist. "

BaranOrnarli wie kann man derjenige sein, der DockerToolbox hat?

Das gleiche Problem hier wie die meisten Leute hier. Aber ich habe es wieder zum Laufen gebracht, indem ich die VM neu gestartet habe.

Windows 10 Education
Docker Toolbox, 17.10.0-ce
VirtualBox 5.2.2

Das Ausführen über die Docker-CLI funktioniert:
docker run -d -p 8080:80 -v $(pwd)/src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf tutorial / nginx

Dasselbe über Docker-Compose ausführen, nicht:
schnipsen
volumes: - ./src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf
Das heißt, bis ich die VM über die VirtualBox-GUI heruntergefahren und das Docker-Schnellstartterminal erneut gestartet habe.

Seitdem hat das wiederholte Zerstören der Container und das Zusammenstellen der Docker keinen Fehler mehr verursacht.

Hoffe das hilft jemandem.

Ich habe das gleiche Problem. In der Zwischenzeit verwende ich den Docker-Ordner für echte Volumes in docker-compose.yml. Dies ist /var/lib/docker/volumes..../file.ext als zeitliche Problemumgehung
(Docker Version 17.12.0-ce, Build c97c6d6)

Wenn Sie ein solches Problem haben, überprüfen Sie auch, ob Sie Ihr Verzeichnis unter Windows freigegeben haben.

Ich bin auf Ubuntu 14.04. Wenn ich den Befehl docker-compose up -d ausführe, wird der folgende Fehler angezeigt:

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

Ich verwende den absoluten Pfad, um das Volume /home/curso-docker/email-worker-compose/nginx/default.conf von meinem Host abzubilden.

Hat jemand eine Idee zu diesem Problem?

@AzeredoGabriel für mich hat das, was @BaranOrnarli zuvor erwähnt hat, wie ein Zauber gewirkt. Setzen Sie die Anmeldeinformationen für Ihr freigegebenes Laufwerk zurück, geben Sie es erneut frei, und es sollte funktionieren. Keine Ahnung, warum es plötzlich überhaupt nicht mehr funktioniert, aber jetzt ist es wieder da.

Gibt es darüber irgendwelche Neuigkeiten? Es scheint immer noch unmöglich, eine einzelne Datei zu mounten

@Karlheinzniebuhr Das war nie ein Problem. Docker ermöglicht das Mounten von Dateien in einen Container, Sie können eine Datei jedoch nicht in ein Verzeichnis mounten oder umgekehrt.

Gibt es darüber irgendwelche Neuigkeiten? Es scheint immer noch unmöglich, eine einzelne Datei zu mounten

Versuchen Sie, die Datei dem vorhandenen Verzeichnis zuzuordnen. Docker versucht immer, ein Verzeichnis zu erstellen, wenn es nicht vorhanden ist.

@ cpuguy83 Natürlich ist es ein Problem. Wir versuchen nicht, Dateien in ein Verzeichnis zu mounten. Wir versuchen, eine einzelne vom Container erstellte Datei als Datei auf dem Host bereitzustellen.

Können wir dieses Problem erneut eröffnen? Funktioniert ab 2019 immer noch nicht. Auf dem neuesten Docker und dem neuesten Docker-Compose, das auf dem neuesten Debian ausgeführt wird.

Sie können nicht vom Container zum Host bereitstellen, sondern nur in die andere Richtung.
Dies ist das gleiche Verhalten für Verzeichnisse und Dateien.

Gleiches Problem mit Docker 19.03.1 und Docker-Compose 1.24.1, während versucht wird, eine Konfigurationsdatei in store/elastic/filebeat:7.3.0 Image mit Volume-Bindung in Docker-Compose.yml zu überschreiben:

    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

Anfangs habe ich versucht, "configs" zu verwenden, aber herausgefunden, dass diese Funktion nur für Schwärme geeignet ist.
Ich versuche, eine Möglichkeit zu finden, eine Konfigurationsdatei für das Standardbild bereitzustellen, ohne eine benutzerdefinierte mit COPY-Konfigurationsdateien zu erstellen.

Gleicher Fehler

$ 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

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

Gibt es eine Chance, dies zu beheben?

Ärgerliches Problem.

Kollegen, überprüfen Sie die Mount-Richtung in Docker-Compose.
Ich hatte die gleichen Probleme, bis mir klar wurde, dass ich falsch lag, sollte so sein:

...
    volumes:
      - /host/file:/docker/file:ro
...
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

HackerWilson picture HackerWilson  ·  3Kommentare

dazorni picture dazorni  ·  3Kommentare

bitver picture bitver  ·  3Kommentare

29e7e280-0d1c-4bba-98fe-f7cd3ca7500a picture 29e7e280-0d1c-4bba-98fe-f7cd3ca7500a  ·  3Kommentare

DhairyashilBhosale picture DhairyashilBhosale  ·  3Kommentare