Je ne parviens pas à reproduire votre problème localement. Si j'essaie d'exposer un système de fichiers encfs en tant que volume Docker, j'obtiens une erreur en essayant de démarrer le conteneur :
FATA[0003] Error response from daemon: Cannot start container <cid>:
setup mount namespace stat /visible: permission denied
Il est donc possible que quelque chose de différent se passe. En tout cas, c'est ce qui a résolu mon problème :
Par défaut, FUSE permet uniquement à l'utilisateur qui a monté un système de fichiers d'avoir accès à ce système de fichiers. Lorsque vous exécutez un conteneur Docker, ce conteneur s'exécute initialement en tant que root .
Vous pouvez utiliser le allow_root ou allow_other options de montage lorsque vous montez le système de fichiers FUSE. Par exemple :
$ encfs -o allow_root /encrypted /other
Ici, allow_root permettra à l'utilisateur root d'avoir accès au point de montage, tandis que allow_other permettra à quiconque d'avoir accès au point de montage (à condition que les autorisations Unix sur le répertoire leur permettent d'accéder).
Si je monte par le système de fichiers encfs en utilisant allow_root , je peux ensuite exposer ce système de fichiers en tant que volume Docker et le contenu de ce système de fichiers est correctement visible depuis l'intérieur du conteneur.
C'est certainement parce que vous avez démarré le démon Docker avant que l'hôte ne monte le point de montage. Dans ce cas, l'inode du nom de répertoire pointe toujours vers le disque local de l'hôte :
ls -i /mounts/
1048579 s3-data-mnt
alors si vous montez en utilisant un démon fuse comme s3fs :
/usr/local/bin/s3fs -o rw -o allow_other -o iam_role=ecsInstanceRole /mounts/s3-data-mnt
ls -i
1 s3-data-mnt
Je suppose que docker effectue une mise en cache bootstrap des noms de répertoire vers les inodes (quelqu'un qui a plus de connaissances à ce sujet que ne peut remplir ce blanc).
Votre commentaire est correct. Si vous redémarrez simplement Docker une fois le montage terminé, votre volume sera correctement partagé de l'hôte vers vos conteneurs. (Ou vous pouvez simplement retarder le démarrage de docker jusqu'à ce que toutes vos montures aient fini de monter)
Ce qui est intéressant (mais qui est complet depuis pour moi maintenant), c'est qu'en quittant le conteneur et en démontant le point de montage sur l'hôte, toutes mes écritures de l'intérieur du conteneur vers le volume partagé sont apparues comme par magie (elles étaient stockées à l'inode sur le disque local de la machine hôte) :
[[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