Docker cifs Mountpunkt mit Unterordner

[ShadowDragon]

Hi,

ich habe einen cifs-share <IP-Adresse/share>. Dieser soll von mehreren Docker-Containern verwendet werden. Jedoch stoße ich hierbei auf ein Problem:

ERROR: for <Container>  Cannot start service <Container>: error while mounting volume '/var/lib/docker/volumes/<Container>_<folder>/_data': failed to mount local volume: mount :/<share>/<subfolder>:/var/lib/docker/volumes/<Container>_<folder>/_data, data: addr=<IP-Adress>: invalid argument
ERROR: Encountered errors while bringing up the project.

Hier der Ausschnitt aus der docker-compose Datei:

version: "3.7"
services:
  <some containers>
    volumes:
      - folder/:/folder
      - ./config:/config
      - ./metadata:/metadata

volumes:
  folder:
    driver_opts:
      type: "cifs"
      o: "username=<username>,password=<password>,uid=101000,gid=101000,file_mode=0755,dir_mode=0755,nounix"
      o: "addr=<IP-Adress>"
      device: ":/<share>/<subfolder>"

Problem ist, dass der eine Container für alle Daten fest definierte Unterordner hat. Dementsprechend muss ich mounten:

• <share>/<subfolder_1>:/folder_1
• <share>/<subfolder_2>:/folder_2

etc.

Dem Weiteren Container ist dies egal und dort kann ich einfach nur <share>:data mounten und den genauen Pfad dann in der config der Anwendung definieren.
Am liebsten möchte ich hier nicht an meine <shares> rangehen und diese so lassen wie aktuell.

Eine weitere Frage: Was sind die besten mount-permissions. Container 1 muss nur lesenden Zugriff haben und Container 2 schreibenden und lesenden. Keiner benötigt aber "Execute"-Permissions (es gibt auch nichts was man ausführen könnte).

EDIT: Keine Ahnung wie relevant dies ist, aber Docker selbst läuft auf Ubuntu 20.04 LTS (headless).

 

[chris221177]

Hallo ShadowDragon,
laut Docker Volumes:

Create CIFS/Samba volumes​

You can mount a Samba share directly in docker without configuring a mount point on your host.

$ docker volume create \
--driver local \
--opt type=cifs \
--opt device=//uxxxxx.your-server.de/backup \
--opt o=addr=uxxxxx.your-server.de,username=uxxxxxxx,password=*****,file_mode=0777,dir_mode=0777 \
--name cif-volume

Notice the addr option is required if using a hostname instead of an IP so docker can perform the hostname lookup.

Übertragen auf Dein Compose file, könntest Du die Zeile mit

o: "addr=<IP-Adress>"

Theoretisch löschen. Wichtig ist aber:

device: ":/<share>/<subfolder>"

Und sollte lauten:

device: "//<IP-ADDR/share/subfolder"

 

[polyphase]

Schau Mal hier, so hat's bei mir auch geklappt:
https://www.computerbase.de/forum/threads/docker-container-welche-nutzt-ihr.2063088/post-27438028

 

[ShadowDragon]

Und sollte lauten:

device: "//<IP-ADDR/share/subfolder"

Schau Mal hier, so hat's bei mir auch geklappt:
https://www.computerbase.de/forum/threads/docker-container-welche-nutzt-ihr.2063088/post-27438028

Hat leider nicht geholfen. :/
Fehlermeldung von 2 Versuchen:

$ sudo -E bash -c 'docker-compose up -d'
Creating network "container_default" with the default driver
Creating volume "container_share1" with default driver
Creating container_container_1 ... error

ERROR: for container_container_1  Cannot start service container: error while mounting volume '/var/lib/docker/volumes/container_share2/_data': failed to mount local volume: mount //<IP-Adress>/share/Subfolder2:/var/lib/docker/volumes/container_share2/_data, data: username=<username>,password=<password>,uid=101000,gid=101000,file_mode=0755,dir_mode=0755,nounix: invalid argument

ERROR: for container  Cannot start service container: error while mounting volume '/var/lib/docker/volumes/container_share2/_data': failed to mount local volume: mount //<IP-Adress>/share/Subfolder2:/var/lib/docker/volumes/container_share2/_data, data: username=<username>,password=<password>,uid=101000,gid=101000,file_mode=0755,dir_mode=0755,nounix: invalid argument
ERROR: Encountered errors while bringing up the project.

------------------------------------------------------------

$ sudo -E bash -c 'docker-compose up -d'
Creating volume "container_share2" with default driver
Creating volume "container_share1" with default driver
Creating container_container_1 ... error

ERROR: for container_container_1  Cannot start service container: error while mounting volume '/var/lib/docker/volumes/container_share1/_data': failed to mount local volume: mount //<IP-Adress>:/share/Subfolder1:/var/lib/docker/volumes/container_share1/_data, data: username=<username>,password=<password>,uid=101000,gid=101000,file_mode=0755,dir_mode=0755,nounix: invalid argument

ERROR: for container  Cannot start service container: error while mounting volume '/var/lib/docker/volumes/container_share1/_data': failed to mount local volume: mount //<IP-Adress>:/share/Subfolder1:/var/lib/docker/volumes/container_share1/_data, data: username=<username>,password=<password>,uid=101000,gid=101000,file_mode=0755,dir_mode=0755,nounix: invalid argument
ERROR: Encountered errors while bringing up the project.

Einmal habe ich es in dem Format device: "//<IP-ADDR/share/subfolder" und einmal in dem Format device: "//<IP-ADDR:/share/subfolder" versucht.

Hier der Ausschnitt aus der compose-Datei:

version: "3.7"
services:
[...]
    volumes:
      - share2:/data_folder2
      - share1:/data_folder1
      - ./config:/config

volumes:
  share2:
    driver_opts:
      type: "cifs"
      o: "username=<username>,password=<password>,uid=101000,gid=101000,file_mode=0755,dir_mode=0755,nounix,rw"
      device: "//<IP-Adress>/share/Subfolder2" # auch getestet mit "//<IP-Adress>:/share/Subfolder2"
  share1:
    driver_opts:
      type: "cifs"
      o: "username=<username>,password=<password>,uid=101000,gid=101000,file_mode=0755,dir_mode=0755,nounix,rw"
      device: "//<IP-Adress>/share/Subfolder1" # auch getestet mit "//<IP-Adress>:/share/Subfolder1"

EDIT: Keine Ahnung wie relevant dies ist, aber Docker selbst läuft auf Ubuntu 20.04 LTS (headless, innerhalb von einem LXC Container).

 

[chris221177]

Die Volumes müssen ja erstellt worden sein und sollten ja unabhängig vom nicht laufenden Container weiterhin vorhanden sein.
Kannst Du mal die Ausgabe von

docker volume inspect share1
docker volume inspect share2

posten?

 

[ShadowDragon]

Kannst Du mal die Ausgabe von

docker volume inspect share1
docker volume inspect share2

posten?

Wie man vlt. erkennt habe ich noch einige weitere Tests durchgeführt, e.g. indem ich noch die cifs Version angegeben habe. Vielleicht ist es auch noch hilfreich zu wissen, dass das ganze in Proxmox selbst mountbar ist.

[
    {
        "CreatedAt": "2022-11-10T13:56:38+01:00",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "container",
            "com.docker.compose.version": "1.29.2",
            "com.docker.compose.volume": "share1"
        },
        "Mountpoint": "/var/lib/docker/volumes/container_share1/_data",
        "Name": "share1",
        "Options": {
            "device": "//<IP-Adress>:/share/Subfolder1",
            "o": "username=<username>,password=<password>,uid=101000,gid=101000,file_mode=0777,dir_mode=0777,nounix,vers=3.0,rw",
            "type": "cifs"
        },
        "Scope": "local"
    }
]
[
    {
        "CreatedAt": "2022-11-10T13:56:38+01:00",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "container",
            "com.docker.compose.version": "1.29.2",
            "com.docker.compose.volume": "share2"
        },
        "Mountpoint": "/var/lib/docker/volumes/container_share2/_data",
        "Name": "share2",
        "Options": {
            "device": "//<IP-Adress>:/share/Subfolder2",
            "o": "username=<username>,password=<password>,uid=101000,gid=101000,file_mode=0777,dir_mode=0777,nounix,vers=3.0,rw",
            "type": "cifs"
        },
        "Scope": "local"
    }
]

Und da ein Kumpel meinte, dass dies vielleicht ein Problem von LXC ist:

# cat /etc/pve/lxc/105.conf
arch: amd64
cores: 4
features: nesting=1
hostname: docker
memory: 6144
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=[...],ip=dhcp,ip6=dhcp,type=veth
onboot: 1
ostype: ubuntu
rootfs: local-zfs:subvol-105-disk-0,size=20G
startup: up=10
swap: 6144
unprivileged: 1

Zudem habe ich gestern noch ein Update des LXC Containers durchgeführt, um zu testen ob dies das Problem behebt: Ubuntu 22.04.1 LTS (GNU/Linux 5.15.64-1-pve x86_64)