Docker: montagens negadas. Os caminhos ... não são compartilhados do OS X e não são conhecidos pelo Docker

O comando docker run -v /var/folders/zz/...produz o seguinte erro.

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 abro o Compartilhamento de arquivos, vejo que / private já está listado.

Se eu tentar adicionar /var/folder/, ele resolverá para /private/var/folders, que é um subconjunto de / private e, portanto, a adição será rejeitada.

Para resumir, me parece que o diretório /var/folders/..é compartilhado pelo OS X como um subdiretório de /privatee, portanto, deve ser conhecido pelo Docker. Qualquer ajuda em resolver isso seria apreciada.

Como experiência, substituí /privateem Compartilhamento de arquivos por /private/var/folderse reiniciei a janela de encaixe, mas o resultado não mudou.

Apenas para uma referência mais completa, este é o script .sh , que executa este script Python , que por sua vez executa o comando docker.

As montagens de volume do Docker para Mac se comportam de maneira diferente do sistema Docker base. Isso ocorre principalmente porque o Docker tenta cumprir as diretrizes de sandbox do sistema de arquivos da Apple.

Conforme mostrado nas preferências do Docker, apenas alguns caminhos são exportados pelo macOS.

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

/varno macOS é um link simbólico para /private. Isso também é verdade para /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

Por que está /tmplistado no painel de compartilhamento, mas /varnão está (embora ambos façam parte de /private)? A documentação do Docker para Mac sobre namespaces de sistema de arquivos explica:

Por padrão, você pode compartilhar arquivos em /Users/, /Volumes/, /private/, e /tmpdiretamente. Para adicionar ou remover árvores de diretório que são exportadas para o Docker, use a guia Compartilhamento de arquivos nas preferências do Docker no menu da baleia -> Preferências -> Compartilhamento de arquivos. (Veja Preferências.)

Todos os outros caminhos usados ​​em -vmontagens de ligação são originados da VM Moby Linux que executa os contêineres do Docker, portanto , os argumentos -v /var/run/docker.sock:/var/run/docker.sockdevem funcionar conforme o esperado. Se um caminho do macOS não for compartilhado e não existir na VM, uma tentativa de montagem de vinculação falhará em vez de criá-lo na VM. Os caminhos que já existem na VM e contêm arquivos são reservados pelo Docker e não podem ser exportados do macOS.

Observe que /var/runé mencionado especificamente aqui como um local que seria montado a partir da VM Linux, em vez do macOS.

Quando você pede uma montagem de volume, as exportações do sistema de arquivos macOS são verificadas primeiro. Se não houver correspondência, a VM Linux onde o Docker está sendo executado será verificada a seguir. Se nenhum deles tiver o caminho solicitado, a montagem falhará.

No seu caso, /varnão é exportado pelo macOS. /varexiste na VM Linux, mas /var/foldersnão. Portanto, o caminho não está disponível e a montagem falha.

Se você alterar o caminho para /private/var, terá êxito, porque o macOS exporta toda a /privateárvore do sistema de arquivos para montagem.

Para tornar as coisas mais portáteis, você pode querer testar em qual plataforma você está executando atualmente e, se for macOS, prefixe o caminho de montagem com /private.

Como solução alternativa :

Mude o caminho de /private/instance1-data:/homepara./instance1-data:/home

No * nix land e, portanto, no Docker, o .indica o diretório atual. Como o macOS é exigente e está cada vez mais exigente com relação ao sandbox, essa parece uma solução viável para o macOS. Basta criar a pasta necessária instance1no mesmo diretório.

Outra vantagem desta solução é que ela elimina a necessidade de executar docker-composecom sudo. Independentemente disso, não causa nenhum dano neste caso, mas ainda assim, é uma vantagem.

Por exemplo, usando o Portainer, este comando funciona para mim:

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

Mas, se eu variar o -v /var:/data, não funcionará. Eu acho (mas não tenho certeza) que é porque o Docker está tentando fazer um mkdir. Então, se eu tento montar -v /var/whatever:/data, mkdir falha porque não tem permissão suficiente e não funciona.

Tenho 2 Macs (High Sierra) e experimentei em ambos. Mesmo problema. Além disso, tentei usar o canal Docker Beta. Acho que entendi a resposta de Dan Lowe: atualizarei esta resposta se funcionar para mim.

Tive um problema semelhante quando criei um diretório /var/tmpem meu Mac que queria montar em meu contêiner docker.

Resolvido adicionando o caminho do diretório a um arquivo da seguinte maneira:

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

Agora eu podia ver o diretório /var/tmpem Docker-> preferência-> recursos-> compartilhamento de arquivo. Em seguida, reiniciei o docker.

Em seguida, resolveu meu problema de montagem.