Ich bin nicht in der Lage, Ihr Problem lokal zu duplizieren. Wenn ich versuche, ein encfs-Dateisystem als Docker-Volume bereitzustellen, erhalte ich beim Versuch, den Container zu starten, eine Fehlermeldung:
FATA[0003] Error response from daemon: Cannot start container <cid>:
setup mount namespace stat /visible: permission denied
Es ist also möglich, dass bei dir etwas anderes vor sich geht. Auf jeden Fall hat dies mein Problem gelöst:
Standardmäßig erlaubt FUSE nur dem Benutzer, der ein Dateisystem gemountet hat, Zugriff auf dieses Dateisystem. Wenn Sie einen Docker-Container ausführen, wird dieser Container anfänglich als root ausgeführt .
Sie können den allow_root verwenden oder allow_other Mount-Optionen, wenn Sie das FUSE-Dateisystem mounten. Zum Beispiel:
$ encfs -o allow_root /encrypted /other
Hier, allow_root erlaubt dem Root-Benutzer den Zugriff auf den Einhängepunkt, während allow_other erlaubt jedem Zugriff auf den Einhängepunkt (vorausgesetzt, dass die Unix-Berechtigungen für das Verzeichnis ihnen Zugriff erlauben).
Wenn ich von encfs filesytem mit allow_root gemountet habe , kann ich dieses Dateisystem dann als Docker-Volume und verfügbar machen der Inhalt dieses Dateisystems ist innerhalb des Containers korrekt sichtbar.
Dies liegt definitiv daran, dass Sie den Docker-Daemon gestartet haben, bevor der Host den Mountpoint gemountet hat. In diesem Fall zeigt der Inode für den Verzeichnisnamen immer noch auf die lokale Festplatte des Hosts:
ls -i /mounts/
1048579 s3-data-mnt
dann, wenn Sie mit einem Fuse-Daemon wie s3fs mounten:
/usr/local/bin/s3fs -o rw -o allow_other -o iam_role=ecsInstanceRole /mounts/s3-data-mnt
ls -i
1 s3-data-mnt
Meine Vermutung ist, dass Docker einige Bootstrap-Caching der Verzeichnisnamen in Inodes durchführt (jemand, der mehr darüber weiß, als diese Lücke ausfüllen kann).
Ihr Kommentar ist richtig. Wenn Sie Docker nach Abschluss des Mountens einfach neu starten, wird Ihr Volume korrekt vom Host zu Ihren Containern geteilt. (Oder Sie können das Starten von Docker einfach verzögern, bis alle Ihre Mounts fertig gemountet sind)
Was interessant ist (aber für mich jetzt komplett ist), ist, dass beim Verlassen des Containers und beim Unmounten des Mountpoints auf dem Host alle meine Schreibvorgänge aus dem Container auf das freigegebene Volume auf magische Weise erschienen (sie wurden am Inode gespeichert). die lokale Festplatte des Host-Rechners):
[[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