Docker: supporti negati. I percorsi ... non sono condivisi da OS X e non sono noti a Docker

Il comando docker run -v /var/folders/zz/...produce il seguente errore.

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.

Quando apro Condivisione file, vedo che / private è già elencato.

Se tento di aggiungere /var/folder/, si risolve in /private/var/folders, che è un sottoinsieme di / private e quindi l'aggiunta viene rifiutata.

Per riassumere, mi sembra che la directory /var/folders/..sia condivisa da OS X come una sottodirectory di /privatee quindi deve essere nota a Docker. Qualsiasi aiuto per risolvere questo problema sarebbe apprezzato.

Come esperimento, ho sostituito /privatein Condivisione file con /private/var/folderse ho riavviato la finestra mobile ma il risultato non è cambiato.

Solo per un riferimento più completo, questo è lo script .sh , che esegue questo script python , che a sua volta esegue il comando docker.

I montaggi di volumi Docker per Mac si comportano in modo diverso rispetto al sistema Docker di base. Ciò è principalmente dovuto al fatto che Docker cerca di conformarsi alle linee guida sandbox del filesystem di Apple.

Come mostrato nelle preferenze di Docker, solo alcuni percorsi vengono esportati da macOS.

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

/varin macOS è un collegamento simbolico in /private. Questo vale anche per /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

Perché è /tmpelencato nel pannello di condivisione, ma /varnon lo è (anche se entrambi ne fanno parte /private)? La documentazione di Docker per Mac sugli spazi dei nomi del file system spiega:

Per impostazione predefinita, è possibile condividere i file in /Users/, /Volumes/, /private/, e /tmpdirettamente. Per aggiungere o rimuovere alberi di directory esportati in Docker, utilizzare la scheda Condivisione file nel menu balena delle preferenze di Docker -> Preferenze -> Condivisione file. (Vedi Preferenze.)

Tutti gli altri percorsi utilizzati nei -vmontaggi bind provengono dalla VM Moby Linux che esegue i contenitori Docker, quindi argomenti come -v /var/run/docker.sock:/var/run/docker.sockdovrebbero funzionare come previsto. Se un percorso macOS non è condiviso e non esiste nella VM, un tentativo di collegarlo al montaggio fallirà invece di crearlo nella VM. I percorsi già esistenti nella VM e che contengono file sono riservati da Docker e non possono essere esportati da macOS.

Nota che /var/runè specificamente menzionato qui come un luogo che verrebbe montato dalla VM Linux, invece che da macOS.

Quando chiedi il montaggio di un volume, le esportazioni del filesystem macOS vengono controllate per prime. Se non c'è corrispondenza lì, viene controllata la VM Linux su cui è in esecuzione Docker. Se nessuno dei due ha il percorso richiesto, il montaggio non riesce.

Nel tuo caso, /varnon viene esportato da macOS. /varesiste nella VM Linux, ma /var/foldersnon lo è. Pertanto, il percorso non è disponibile e il montaggio non riesce.

Se modifichi il percorso in /private/var, avrà successo, perché macOS esporta l'intero /privatealbero del filesystem per il montaggio.

Per rendere le cose più portabili, potresti voler testare su quale piattaforma sei attualmente in esecuzione e, se è macOS, anteporre al percorso di montaggio /private.

Come soluzione alternativa :

Cambia il percorso da /private/instance1-data:/homea./instance1-data:/home

Nella terra * nix e quindi, Docker, .indica la directory corrente. Poiché macOS è pignolo e diventa ancora più esigente riguardo al sandboxing, questa sembra una soluzione praticabile per macOS. Basta creare la cartella necessaria per instance1nella stessa directory.

Un altro vantaggio di questa soluzione è che elimina la necessità di eseguire docker-composecon sudo. Indipendentemente da ciò, non provoca danni in questo caso, ma comunque è un vantaggio.

Ad esempio, usando Portainer, questo comando funziona per me:

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

Ma, se modifico il -v /var:/datatutto, non funzionerà. Penso (ma non sono sicuro) che sia perché Docker sta cercando di fare un mkdir. Quindi, se provo a montare -v /var/whatever:/data, mkdir fallisce perché non è abbastanza permesso e non funziona.

Ho 2 Mac (High Sierra) e l'ho provato su entrambi. Stesso problema. Inoltre, ho provato a utilizzare il canale Docker Beta. Penso di aver capito la risposta di Dan Lowe: aggiornerò questa risposta se funziona per me.

Ho avuto un problema simile in cui avevo creato una directory /var/tmpnel mio Mac che volevo montare nel mio container Docker.

Risolto aggiungendo il percorso della directory a un file come segue:

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

Ora potrei vedere la directory /var/tmpin Docker-> preferenza-> risorse-> condivisione di file. Quindi ho riavviato la finestra mobile.

Ha quindi risolto il mio problema di montaggio.