Impossible d’exposer un volume basé sur un fusible à un conteneur Docker

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 : 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’accéder à ce système de fichiers. Lorsque vous exécutez un conteneur Docker, ce conteneur est initialement exécuté en tant que root .

Vous pouvez utiliser les options de assembly allow_root ou allow_other lorsque vous montez le système de fichiers FUSE. Par exemple:

 $ encfs -o allow_root /encrypted /other 

Dans ce cas, allow_root permettra à l’utilisateur root d’accéder au sharepoint assembly, alors que allow_other permettra à quiconque d’accéder au sharepoint assembly (à condition que les permissions Unix sur le répertoire leur permettent d’y accéder).

Si je monte avec le système de fichiers encfs en utilisant allow_root , je peux alors 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.

Cela est certainement dû au fait que vous avez démarré le démon docker avant que l’hôte ne monte le sharepoint assembly. Dans ce cas, l’inode du nom du 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 fusible 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 

J’imagine que docker fait de la mise en cache bootstrap des noms de répertoire dans inodes (quelqu’un qui a plus de connaissances que cela peut remplir ce blanc).

Votre commentaire est correct. Si vous redémarrez simplement docker une fois le assembly 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 tous vos supports aient fini de monter)

Ce qui est intéressant (mais complet car pour moi maintenant) est que, à la sortie du conteneur et au désassemblage du sharepoint assembly sur l’hôte, toutes mes écritures du conteneur au volume partagé apparaissaient comme par magie (elles étaient stockées à l’inode le disque local des machines hôtes):

 [root@host s3-data-mnt]# echo foo > bar [root@host 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 [root@host s3-data-mnt]# docker run -ti -v /mounts/s3-data-mnt:/s3-data busybox /bin/bash root@5592454f9f4d:/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 .. root@5592454f9f4d:/s3-data# echo baz > beef root@5592454f9f4d:/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 root@5592454f9f4d:/s3-data# exit exit [root@host 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 [root@host /]# umount -l s3-data-mnt [root@host /]# ls -als [root@ip-10-0-3-233 /]# 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 

Vous pourrez peut-être contourner ce nsenter en nsenter appel de assembly dans nsenter pour le monter dans le même espace de noms de assembly Linux que le démon docker, par exemple.

 nsenter -t "$PID_OF_DOCKER_DAEMON" encfs ... 

La question est de savoir si cette approche survivra à un redémarrage du démon. 😉