No puedo duplicar su problema localmente. Si trato de exponer un sistema de archivos encfs como un volumen de Docker, obtengo un error al intentar iniciar el contenedor:
FATA[0003] Error response from daemon: Cannot start container <cid>:
setup mount namespace stat /visible: permission denied
Así que es posible que tengas algo diferente. En cualquier caso, esto es lo que resolvió mi problema:
De forma predeterminada, FUSE solo permite que el usuario que montó un sistema de archivos tenga acceso a ese sistema de archivos. Cuando ejecuta un contenedor Docker, ese contenedor se ejecuta inicialmente como root .
Puedes usar el allow_root o allow_other opciones de montaje al montar el sistema de archivos FUSE. Por ejemplo:
$ encfs -o allow_root /encrypted /other
Aquí, allow_root permitirá que el usuario root tenga acceso al punto de montaje, mientras que allow_other permitirá que cualquiera tenga acceso al punto de montaje (siempre que los permisos de Unix en el directorio les permitan acceder).
Si monté por el sistema de archivos encfs usando allow_root , luego puedo exponer ese sistema de archivos como un volumen de Docker y el contenido de ese sistema de archivos se ve correctamente desde el interior del contenedor.
Esto definitivamente se debe a que inició el demonio docker antes de que el host montara el punto de montaje. En este caso, el inodo para el nombre del directorio sigue apuntando al disco local del host:
ls -i /mounts/
1048579 s3-data-mnt
luego, si montas usando un demonio fusible como s3fs:
/usr/local/bin/s3fs -o rw -o allow_other -o iam_role=ecsInstanceRole /mounts/s3-data-mnt
ls -i
1 s3-data-mnt
Supongo que la ventana acoplable realiza un almacenamiento en caché de arranque de los nombres de directorio en inodos (alguien que tiene más conocimiento de esto que puede completar este espacio en blanco).
Tu comentario es correcto. Si simplemente reinicia la ventana acoplable después de que el montaje haya finalizado, su volumen se compartirá correctamente desde el host a sus contenedores. (O simplemente puede retrasar el inicio de la ventana acoplable hasta que todas sus monturas hayan terminado de montarse)
Lo que es interesante (pero me completa desde ahora) es que al salir del contenedor y desmontar el punto de montaje en el host, todas mis escrituras desde dentro del contenedor al volumen compartido aparecieron mágicamente (estaban siendo almacenadas en el inodo en el disco local de la máquina host):
[[email protected] s3-data-mnt]# echo foo > bar
[[email protected] s3-data-mnt]# ls /mounts/s3-data-mnt
total 6
1 drwxrwxrwx 1 root root 0 Jan 1 1970 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
[[email protected] s3-data-mnt]# docker run -ti -v /mounts/s3-data-mnt:/s3-data busybox /bin/bash
[email protected]:/mounts/s3-data# ls -als
total 8
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 .
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 ..
[email protected]:/s3-data# echo baz > beef
[email protected]:/s3-data# ls -als
total 9
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 .
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 beef
[email protected]:/s3-data# exit
exit
[[email protected] s3-data-mnt]# ls /mounts/s3-data-mnt
total 6
1 drwxrwxrwx 1 root root 0 Jan 1 1970 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
[[email protected] /]# umount -l s3-data-mnt
[[email protected] /]# ls -als
[[email protected] /]# ls -als /s3-stn-jira-data-mnt/
total 8
4 drwxr-xr-x 2 root root 4096 Sep 16 17:28 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar