Non sono in grado di duplicare il tuo problema localmente. Se provo a esporre un filesystem encfs come volume Docker, ottengo un errore nel tentativo di avviare il contenitore:
FATA[0003] Error response from daemon: Cannot start container <cid>:
setup mount namespace stat /visible: permission denied
Quindi è possibile che tu stia succedendo qualcosa di diverso. In ogni caso, questo è ciò che ha risolto il mio problema:
Per impostazione predefinita, FUSE consente solo all'utente che ha montato un filesystem di avere accesso a quel filesystem. Quando esegui un contenitore Docker, quel contenitore viene inizialmente eseguito come root .
Puoi usare il allow_root o allow_other opzioni di mount quando monti il filesystem FUSE. Ad esempio:
$ encfs -o allow_root /encrypted /other
Qui, allow_root consentirà all'utente root di avere accesso al mountpoint, mentre allow_other consentirà a chiunque di avere accesso al punto di montaggio (a condizione che i permessi Unix sulla directory consentano loro l'accesso).
Se ho montato il file system encfs usando allow_root , posso quindi esporre quel filesystem come volume Docker e i contenuti di quel filesystem sono correttamente visibili dall'interno del contenitore.
Questo è sicuramente perché hai avviato il demone docker prima che l'host montasse il punto di montaggio. In questo caso l'inode per il nome della directory punta ancora al disco locale dell'host:
ls -i /mounts/
1048579 s3-data-mnt
quindi se monti usando un demone fuse come s3fs:
/usr/local/bin/s3fs -o rw -o allow_other -o iam_role=ecsInstanceRole /mounts/s3-data-mnt
ls -i
1 s3-data-mnt
La mia ipotesi è che la finestra mobile esegua una memorizzazione nella cache bootstrap dei nomi delle directory negli inode (qualcuno che ne ha più conoscenza di quanto possa riempire questo spazio vuoto).
Il tuo commento è corretto. Se riavvii semplicemente la finestra mobile al termine del montaggio, il tuo volume verrà condiviso correttamente dall'host ai tuoi contenitori. (Oppure puoi semplicemente ritardare l'avvio della finestra mobile fino al termine del montaggio di tutti i tuoi supporti)
Ciò che è interessante (ma rende completo da allora per me ora) è che all'uscita dal contenitore e smontando il punto di montaggio sull'host tutte le mie scritture dall'interno del contenitore al volume condiviso sono apparse magicamente (erano state memorizzate nell'inode su il disco locale della macchina 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