Tengo un recurso compartido nfs que puedo montar sin problemas, pero la ventana acoplable no quiere una barra:/
Si no incluyo los volúmenes nfs, se instala bien.
Lo he intentado con los permisos en el recurso compartido nfs configurados en "chmod 777" y "chown nadie: nadie".
Puedo conectarme desde mi mac y escribir en el recurso compartido nfs.
> docker volume create --driver local \ --opt type=nfs4 \ --opt o=addr=192.168.1.48,rw \ --opt device=:/mnt/tank/virtualisation/database \ database > docker volume inspect database [ { "CreatedAt": "2019-05-14T17:14:54+10:00", "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/database/_data", "Name": "database", "Options": { "device": ":/mnt/tank/virtualisation/database", "o": "addr=192.168.1.48,rw", "type": "nfs4" }, "Scope": "local" } ] > docker run --name mysql -v database:/var/lib/mysql -v database:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=root -d percona:ps-8 docker: Error response from daemon: failed to copy file info for /var/lib/docker/volumes/database/_data: failed to chown /var/li b/docker/volumes/database/_data: lchown /var/lib/docker/volumes/database/_data: operation not permitted.Detalles del sistema.
Servidor (FreeNAS)
> showmount -e 192.168.1.48 Exports list on 192.168.1.48: /mnt/tank/virtualisation/database EveryoneMáquina virtual Debian 9.9 con docker
> docker version Client: Version: 18.09.6 API version: 1.39 Go version: go1.10.8 Git commit: 481bc77 Built: Sat May 4 02:36:00 2019 OS/Arch: linux/amd64 Experimental: false Server: Docker Engine - Community Engine: Version: 18.09.6 API version: 1.39 (minimum version 1.12) Go version: go1.10.8 Git commit: 481bc77 Built: Sat May 4 01:59:36 2019 OS/Arch: linux/amd64 Experimental: falseEnfrenté el mismo problema con un recurso compartido NFS que necesito montar como volumen en un contenedor nginx.
En mi caso, agregar no_root_squash como opción para compartir NFS resolvió el problema: esta opción hace que el usuario/grupo raíz del cliente NFS se asigne al usuario/grupo raíz del servidor NFS, como puede leer, por ejemplo , aquí .
Entonces, finalmente mi /etc/exports se ve así:
/tank/honey-files 172.29.6.0/16(rw,sync,no_subtree_check,no_root_squash)y puedo montarlo en un contenedor creando un volumen
docker volume create honey-files --driver local --opt type=nfs --opt o=addr=172.29.6.200 --opt device=:/tank/honey-files y usarlo con docker run / docker service create :
docker run --name nginx --rm -v honey-files:/usr/share/nginx/html -p 30001:80 nginx:latest docker service create --name nginx -p 30002:80 --mount 'src=honey-files,target=/usr/share/nginx/html' nginx:latestLa pregunta es muy antigua, pero... ¡Espero que esta respuesta pueda ayudarte!
Tuvimos un problema similar con un volumen montado a través de NFS.
no_root_squash parece funcionar (así que, ¡gracias por la sugerencia anterior a Pietro Martinelli!), pero definitivamente hay razones válidas desde una perspectiva de seguridad para no hacerlo.
Pudimos sortear este problema agregando la opción nocopy al montaje del volumen, como -v volume_name:/foo/bar:nocopy
Esto, como sugiere la opción, evitará la inicialización de Docker (es decir, si hay archivos en la ubicación del volumen dentro de la imagen, no se copiarán), pero para el caso de uso mencionado (y el nuestro) esto no es un problema.
Más antecedentes y otras opciones también se pueden encontrar aquí:
El problema solo parece ocurrir si el volumen NFS está completamente vacío, por lo que otra solución sería simplemente crear un archivo ficticio en el volumen.