Docker: Reittiere verweigert. Die Pfade… werden von OS X nicht gemeinsam genutzt und sind Docker nicht bekannt

Der Befehl docker run -v /var/folders/zz/...erzeugt den folgenden Fehler.

docker: Error response from daemon: Mounts denied: 
The paths /var/folders/zz/... and /var/folders/zz/...
are not shared from OS X and are not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.

Wenn ich die Dateifreigabe öffne, wird / private bereits aufgelistet.

Wenn ich versuche hinzuzufügen /var/folder/, wird es in aufgelöst /private/var/folders, was eine Teilmenge von / private ist, und daher wird das Hinzufügen abgelehnt.

Zusammenfassend sieht es für mich so aus, als würde das Verzeichnis /var/folders/..von OS X als Unterverzeichnis von /privateDocker gemeinsam genutzt und muss daher Docker bekannt sein. Jede Hilfe bei der Lösung dieses Problems wäre dankbar.

Als Experiment habe ich das Docker /privatein File Sharing durch ersetzt /private/var/foldersund neu gestartet, aber das Ergebnis hat sich nicht geändert.

Nur für eine vollständigere Referenz ist dies das .sh-Skript , das dieses Python-Skript ausführt , das wiederum den Docker-Befehl ausführt.

Docker für Mac- Volume-Mounts verhalten sich anders als das Basis-Docker-System. Dies liegt hauptsächlich daran, dass Docker versucht, die Sandbox-Richtlinien für das Dateisystem von Apple einzuhalten.

Wie in den Docker-Einstellungen gezeigt, werden nur bestimmte Pfade von macOS exportiert.

• /Users
• /Volumes
• /tmp
• /private

/varin macOS ist eine symbolische Verknüpfung in /private. Das gilt auch für /tmp:

$ ls -ld /tmp /var
lrwxr-xr-x@ 1 root  wheel  11 Jan 26 16:18 /tmp -> private/tmp
lrwxr-xr-x@ 1 root  wheel  11 Jan 26 16:18 /var -> private/var

Warum wird /tmpes im Freigabebereich aufgeführt, aber /varnicht (obwohl beide Teil davon sind /private)? In der Dokumentation zu Docker für Mac zu Dateisystem-Namespaces wird Folgendes erläutert:

Standardmäßig können Sie Dateien in gemeinsam nutzen /Users/, /Volumes/, /private/, und /tmpdirekt. Verwenden Sie zum Hinzufügen oder Entfernen von Verzeichnisbäumen, die nach Docker exportiert werden, die Registerkarte Dateifreigabe im Walmenü der Docker-Einstellungen -> Einstellungen -> Dateifreigabe. (Siehe Einstellungen.)

Alle anderen Pfade, die in -vBindungs-Mounts verwendet werden, stammen von der Moby Linux-VM, auf der die Docker-Container ausgeführt werden. Daher-v /var/run/docker.sock:/var/run/docker.sock sollten Argumente wie erwartet funktionieren. Wenn ein macOS-Pfad nicht freigegeben ist und in der VM nicht vorhanden ist, schlägt der Versuch, den Mount zu binden, fehl, anstatt ihn in der VM zu erstellen. Pfade, die bereits in der VM vorhanden sind und Dateien enthalten, werden von Docker reserviert und können nicht aus macOS exportiert werden.

Beachten Sie, dass dies /var/runhier ausdrücklich als Ort erwähnt wird, der von der Linux-VM anstelle von macOS bereitgestellt wird.

Wenn Sie nach einem Volume-Mount fragen, werden zuerst die Exporte des macOS-Dateisystems überprüft. Wenn dort keine Übereinstimmung vorliegt, wird als Nächstes die Linux-VM überprüft, auf der Docker ausgeführt wird. Wenn keiner von ihnen den von Ihnen angeforderten Pfad hat, schlägt die Bereitstellung fehl.

In Ihrem Fall /varwird nicht von macOS exportiert. /varexistiert in der Linux-VM, ist es aber /var/foldersnicht. Daher ist der Pfad nicht verfügbar und die Bereitstellung schlägt fehl.

Wenn Sie den Pfad in ändern /private/var, ist dies erfolgreich, da macOS den gesamten /privateDateisystembaum zum Mounten exportiert .

Um die Portabilität zu verbessern, möchten Sie möglicherweise testen, auf welcher Plattform Sie gerade arbeiten. Wenn es sich um MacOS handelt, müssen Sie dem Mount-Pfad das Präfix voranstellen /private.

Als alternative Lösung:

Ändern Sie den Pfad von /private/instance1-data:/homenach./instance1-data:/home

Im * nix-Land und damit in Docker .gibt das das aktuelle Verzeichnis an. Da macOS beim Sandboxen immer wählerischer wird, scheint dies eine praktikable Lösung für macOS zu sein. Erstellen Sie einfach den gewünschten Ordner instance1im selben Verzeichnis.

Ein weiterer Vorteil dieser Lösung besteht darin, dass sie nicht mehr ausgeführt docker-composewerden muss sudo. Unabhängig davon verursacht es in diesem Fall keinen Schaden, aber dennoch ist das ein Plus.

Mit Portainer funktioniert dieser Befehl beispielsweise für mich:

docker run -d --restart unless-stopped -p 9000:9000 \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /var:/data portainer/portainer --no-auth

Aber wenn ich das -v /var:/dataüberhaupt ändere, wird es nicht funktionieren. Ich denke (aber nicht sicher), dass es daran liegt, dass Docker versucht, ein mkdir zu machen. Wenn ich also versuche zu mounten -v /var/whatever:/data, schlägt mkdir fehl, weil nicht genügend Berechtigungen vorhanden sind und es nicht funktioniert.

Ich habe 2 Macs (High Sierra) und habe es auf beiden ausprobiert. Gleiches Problem. Außerdem habe ich versucht, den Docker Beta-Kanal zu verwenden. Ich glaube, ich verstehe die Antwort von Dan Lowe: Ich werde diese Antwort aktualisieren, wenn das für mich funktioniert.

Ich hatte ein ähnliches Problem, als ich /var/tmpauf meinem Mac ein Verzeichnis erstellt hatte, das ich in meinen Docker-Container einbinden wollte.

Es wurde behoben, indem der Verzeichnispfad wie folgt zu einer Datei hinzugefügt wurde:

$ cat ~/Library/Group\ Containers/group.com.docker/settings.json  
{
  "filesharingDirectories" : [
    "\/Users",
    "\/Volumes",
    "\/private",
    "\/tmp",
    "\/var\/tmp"
  ],
…

Jetzt konnte ich das Verzeichnis /var/tmpunter Docker-> Einstellungen-> Ressourcen-> Dateifreigabe sehen. Dann habe ich den Docker neu gestartet.

Es löste dann mein Montageproblem.