Docker: montajes denegados. Las rutas ... no se comparten desde OS X y Docker no las conoce

El comando docker run -v /var/folders/zz/...produce el siguiente error.

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.

Cuando abro Compartir archivos, veo que / privado ya aparece en la lista.

Si intento agregar /var/folder/, se resuelve en /private/var/folders, que es un subconjunto de / private y, por lo tanto, se rechaza la adición.

En resumen, me parece que /var/folders/..OS X comparte el directorio como un subdirectorio de /privatey, por lo tanto, Docker debe conocerlo. Se agradecería cualquier ayuda para resolver este problema.

Como experimento, reemplacé el uso /privatecompartido de archivos con /private/var/foldersy reinicié la ventana acoplable, pero el resultado no cambió.

Solo para una referencia más completa, este es el script .sh , que ejecuta este script de Python , que a su vez ejecuta el comando docker.

Los montajes de volumen de Docker para Mac se comportan de manera diferente al sistema Docker base. Esto se debe principalmente a que Docker intenta cumplir con las pautas de la zona de pruebas del sistema de archivos de Apple.

Como se muestra en las preferencias de Docker, macOS solo exporta ciertas rutas.

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

/varen macOS es un enlace simbólico a /private. Eso también es cierto 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 qué /tmpaparece en el panel para compartir, pero /varno (aunque ambos forman parte de /private)? La documentación de Docker para Mac sobre los espacios de nombres del sistema de archivos explica:

Por defecto, se puede compartir archivos en /Users/, /Volumes/, /private/, y /tmpdirectamente. Para agregar o eliminar árboles de directorios que se exportan a Docker, use la pestaña Compartir archivos en el menú de preferencias de Docker -> Preferencias -> Compartir archivos. (Ver Preferencias).

Todas las demás rutas utilizadas en los -vmontajes de enlace se obtienen de la máquina virtual Moby Linux que ejecuta los contenedores Docker, por lo que los argumentos como -v /var/run/docker.sock:/var/run/docker.sockdeberían funcionar como se esperaba. Si una ruta de macOS no se comparte y no existe en la VM, un intento de vincular el montaje fallará en lugar de crearla en la VM. Docker reserva las rutas que ya existen en la máquina virtual y contienen archivos y no se pueden exportar desde macOS.

Tenga en cuenta que /var/runaquí se menciona específicamente como un lugar que se montaría desde la máquina virtual de Linux, en lugar de desde macOS.

Cuando solicita un montaje de volumen, primero se comprueban las exportaciones del sistema de archivos macOS. Si no hay ninguna coincidencia allí, la máquina virtual de Linux donde se ejecuta Docker se marca a continuación. Si ninguno de ellos tiene la ruta solicitada, entonces el montaje falla.

En su caso, /varmacOS no lo exporta. /varexiste en la máquina virtual de Linux, pero /var/foldersno. Por lo tanto, la ruta no está disponible y el montaje falla.

Si cambia la ruta a /private/var, tendrá éxito, porque macOS exporta todo el /privateárbol del sistema de archivos para su montaje.

Para hacer las cosas más portátiles, es posible que desee probar en qué plataforma se está ejecutando actualmente y, si es macOS, prefijo la ruta de montaje con /private.

Como alternativa solución :

Cambiar el camino de /private/instance1-data:/home a./instance1-data:/home

En la tierra * nix y, por lo tanto, Docker, .indica el directorio actual. Dado que macOS es quisquilloso y se vuelve aún más exigente con el sandboxing, esta parece una solución viable para macOS. Simplemente cree la carpeta necesaria parainstance1 en el mismo directorio.

Otra ventaja de esta solución es que elimina la necesidad de ejecutar docker-compose con sudo. Independientemente, no causa ningún daño en este caso, pero aún así, eso es una ventaja.

Como ejemplo, usando Portainer, este comando funciona para mí:

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

Pero, si varío -v /var:/dataen absoluto, no funcionará. Creo (pero no estoy seguro) que es porque Docker está tratando de hacer un mkdir. Entonces, si trato de montar-v /var/whatever:/data , mkdir falla porque no tiene suficiente permiso y no funciona.

Tengo 2 Mac (High Sierra) y lo probé en ambos. El mismo problema. Además, intenté usar el canal Docker Beta. Creo que entiendo la respuesta de Dan Lowe: actualizaré esta respuesta si eso funciona para mí.

Tuve un problema similar donde había creado un directorio /var/tmp en mi Mac que quería montar en mi contenedor docker.

Lo resolvió agregando la ruta del directorio a un archivo de la siguiente manera:

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

Ahora pude ver el directorio /var/tmp en Docker-> preferencia-> recursos-> intercambio de archivos. Luego reinicié la ventana acoplable.

Luego resolvió mi problema de montaje.