nextcloud-data mount in unprivilegiertem LXC verhält sich seltsam

[KrawallKurt]

Hallo zusammen,
Ich versuche aktuell, eine Nextcloud zum Laufen zu bringen, bei der ich die Daten gerne auf dem NAS ablegen möchte, den Container selbst aber auf dem Host. Dazu habe ich auf dem PVE über die fstab einen CIFS Share (uid und gid = 100033 [www-data]) eingebunden und per mount an den Nextcloud Container weiter gegeben. Dann gab es aber bei der Installation mit dem Turnkey Linux Nextcloud Template einen Fehler, dass die .ocdata Datei im Datenordner fehlt:
Your data directory is invalid. Ensure there is a file called ".ocdata" in the root of the data directory.

Ich dachte, vielleicht liegt das am CIFS mount und habe diesen wieder entfernt. Das seltsame ist: Auch, wenn ich einfach so einen Pfad vom PVE an den LXC mounte, gibt es den Fehler. Ich kann mir das irgendwie nicht erklären, da die Rechte eigentlich da sind und bei der Installation auch andere Dateien vom LXC erstellt werden. Kann mir das jemand von euch erklären? Gibt es irgendwie Restriktionen, dass der LXC keine hidden files erstellen darf oder so?

Zum Reproduzieren:

1. mkdir /mnt/nextcloud_data
2. chown 100033:100033 /mnt/nextcloud_data
3. LXC mit TKL Nextcloud Template (debian-12-turnkey-nextcloud_18.0-1_amd64.tar.gz) erstellen
4. pct set 101 -mp0 /mnt/nextcloud_data/,mp=/var/www/nextcloud-data/
5. LXC starten
6. Installation durchführen
7. Obiger Fehler erscheint

Ohne den mount läuft die Installation ohne Fehler durch. Woran kann das liegen?

Außerdem nehme ich auch gerne Tipps zur generellen Vorgehensweise an.

• Macht SMB/CIFS bei diesem Vorhaben Sinn, oder wäre NFS besser?
  • SMB verschluckt ja die Linux Permissions, was eigentlich nicht so toll ist. Ist das bei NFS anders?
  • Bei NFS konnte ich nur NFSv3 im PVE einbinden und wenn ich es richtig verstehe, ist dabei der einzige "Sicherheitsmechanismus" die IP des Hosts. Das wäre mir eher nicht genug.
• Für einen unprivilegierten Container habe ich mich entschieden, weil ich u.a. die Nextcloud App Recognize benutzen möchte und die zB. im offiziellen Nextcloud Docker Container (basierend auf Alpine, keine glibc) keine HW-Unterstützung für Tensorflow bietet. Wie wäre das bei einer "vollwertigen" VM? Hat die virtualisierte CPU da AVX Instruktionen? Bezüglich Sicherheit: Die Nextcloud wird nicht ans offene Internet gehen, sondern nur lokal, bzw per VPN erreichbar sein. Von daher gefällt mir eigentlich die Lösung per unprivilegiertem LXC ganz gut.

Vielen Dank für euren Input im Voraus

 

[KrawallKurt]

Ich bin ein kleines Stück weiter gekommen. Nach dieser Anleitung habe ich meine /etc/pve/lxc/101.conf um folgendes erweitert:

lxc.idmap: u 0 100000 33
lxc.idmap: g 0 100000 33
lxc.idmap: u 33 33 1
lxc.idmap: g 33 33 1
lxc.idmap: u 34 100034 65502
lxc.idmap: g 34 100034 65502

und auch die /etc/subuid und /etc/subgid jeweils um root:33:1 erweitert.

Dadurch läuft die Installation durch, allerdings gehört danach das Verzeichnis /var/www/nextcloud innerhalb des Containers dann nobody. Also ist anscheinend der www-data user innerhalb des Containers kaputt.. chown des /var/www/nextcloud Verzeichnis ist nicht erlaubt, auch für root nicht. Was kann man da tun?

root@nextcloud ~# ls -l /var/www/
total 8
drwxr-xr-x 15 nobody   nogroup  4096 Sep 28 00:12 nextcloud
drwxrwx---  2 www-data www-data 4096 Feb  5 20:19 nextcloud-data

 

[fireon]

Die Nextcloud wird nicht ans offene Internet gehen, sondern nur lokal, bzw per VPN erreichbar sein. Von daher gefällt mir eigentlich die Lösung per unprivilegiertem LXC ganz gut.

Dann könntest du ja einen privilegierten nehmen. Dann sollte es funktionieren. Unprivilegiert wäre ja wenn du sie öffentlich in's Internet hängst. Ansonsten unter "Features" die Option "Nesting" aktivieren. Hilft das noch nicht, "Device Nodes erzeugen". Ich verwende Nextcloud mit einer vollwertigen VM. Damit funktioniert es immer. (Ubuntu 22.04 LTS) -> Plain installiert. CPU "IMMER" auf HOST stellen, sofern du keinen HA-Cluster betreibst. Damit hast du alle CPUflags die deine Phy Cpu unterstützt.

 

[KrawallKurt]

Hey, danke für die Rückmeldung. Das mit dem CPU Type ist ein guter Tipp, danke dafür. Zu meinem ursprünglichen Problem bin ich mittlerweile auf die Lösung gekommen und möchte die noch dokumentieren, falls mal jemand drüber stolpert.

Das Turnkey Linux Nextcloud Template enthält schon Dateien der Verzeichnisse /var/www/nextcloud und /var/www/nextcloud-data, die beim Entpacken bereits mit dem User 100033 angelegt werden. Durch nachträgliches Mounting auf /var/www/nextcloud-data werden die ursprünglichen Daten des Verzeichnisses verdeckt, was zu dem Problem im ersten Post geführt hat. Durch das Usermapping nach dem Erstellen des Containers gab es das Problem im zweiten Post, weil das Verzeichnis /var/www/nextcloud ja noch dem User 100033 gehört, es den im Container aber nicht mehr gibt. Kann gelöst werden durch mounten des Containers im Host und chown.