Nextcloud im LXC - Datenverzeichnis als NFS einbinden

[MikeyMike]

Hallo zusammen,

da ich nun kurz vor dem Aufgeben bin hoffe das mir doch noch jemand helfen kann bevor ich mein Vorhaben in eine VM verlegen muss.
Ich möchte mir eine neue Nextcloud (derzeit gehostet auf einer NAS) auf meinem Qotom mit Proxmox einrichten. Linux technisch bin ich leider noch nicht ganz so fit.

Hierzu habe ich zuerst eine MariaDB in einem eigenen Container installiert. Da ich die DB evtl. auch noch für andere Dinge nutzen möchte und diese auch separat von der NGINX/Nextcloud installation betreiben und backupen wollte, denke ich das ist erstmal OK so.

In einem zweiten Container habe ich NGINX, PHP, Redis, .... für die Nextcloud installiert und alles soweit vorbereitet, das die Installation über HTTP funktioniert, da ich die SSL Terminierung über meinen HAPROXY der auf der speraten OPNSense Firewall machen möchte um das Handling des Letsencrypt Zertifikats zu vereinfachen.

Jetzt das erste große Problem:
Die Daten der Nextcloud möchte ich gerne auf meine NAS via NFS ablegen, SMB ist mir zu unperformant. Ich habe bereits mehrere Tage erfolglos damit verbracht die NFS Freigabe meiner NAS im Container einzubinden. Von manuellen Ändern von UIDs und GUIDs auf der NAS und im Container angefangen habe ich glaube ich jetzt alles durch was in meiner Macht steht ;-) Letztendlich bin ich jetzt erst darauf gestoßen, das das Problem nicht meine NAS sondern in diesem Fall Proxmox selber ist. Auch hier habe ich bereits viele Dinge gelesen und erfolglos versucht. Das Aktivieren von Nesting hat leider auch nichts geholfen. Der NFS Share selbst kann unter dem Proxmox Host via mount unproblematisch eingebunden werden. Die erzeugten Testdteien haben dann den Besitzer root.

Den Container als priviligiert laufen zu lassen, wo angeblich das Einbinden via NFS funktionieren soll, empfinde ich Sicherheitstechnisch nach meinem jetzigen Kenntnisstand als absolute Katastrophe. Die Cloud soll ja via DMZ ans Netz. Ein "Bind" über das Proxmox hostsystem soll ebenfalls unschön sein, da sich das System evtl. mal aufhängen kann oder es auch Probleme bei einem reboot geben kann. Bitte korrigiert mich wenn ich hier etwas falsch verstanden habe - und nochmal: Bin erst kurz in Linux und Proxmox unterwegs -dehalb bitte etwas um Nachsicht falls ich hier was falsch wiedergebe.

Letztendlich möchte ich den share so einbinden, das Nextcloud über den User www-data:www-data darauf zugreifen kann und auch die entsprechenden User-Rechte exakt so funktionieren als wäre es das lokale Storage.
Da es doch eigentlich kein sonderbares Setup ist bin ich verwundert das soviele damit Probleme haben und es scheinbar noch kein best practise dafür gibt als alles im Gesamten in einer VM oder Container zu betreiben.

Freue mich über jegliche Hilfe um meine letzten freien Tage nicht mit der NFS Freigabe zu verschwenden. HAPROXY wartet doch noch
Wenn jemand Zeit hat gerne auch via Tele / Teamviewer gegen nen lecker Bierchen

 

[wolfgang]

Hallo,
NFS ist immer im Host Kernel also wenn es hängt hängt auch der Host das ist bei NFS so.
Ich persönlich würde an deine stelle den NFS am Host machen und dann einen Bindmount [1] in den Container machen.
Wenn du was ich nachvollziehen kann unprivilegierten Container verwenden willst musst du noch ein UID remapping machen[2].

1.) https://pve.proxmox.com/wiki/Linux_Container#_bind_mount_points
2.) https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

 

[MikeyMike]

Hallo Wolfgang,

erstmal besten Dank für die Info.

Was würde denn passieren, wenn der Proxmox host bootet und nicht auf das NFS Verzeichnis zugreifen kann? Geht es dann nach kurzer Zeit weiter oder bleibt das System hängen?

Es gibt wie ich soeben gelesen habe ja auch die Möglichkeit anstatt fstab auch autofs zu nutzen. Wäre das dann nicht immer die bessere Alternative anstatt fstab?

 

[wolfgang]

Was würde denn passieren, wenn der Proxmox host bootet und nicht auf das NFS Verzeichnis zugreifen kann? Geht es dann nach kurzer Zeit weiter oder bleibt das System hängen?

Du hast keine Daten in dem Container. Du siehst das leere Dir und wenn du schreibst wirst du lokal schreiben.

 

[MikeyMike]

Hallo zusammen,

anbei eine Anleitung falls jemand anderes hier über den Thread stolpern sollte.
Für mich war das ganze als "Neuling" nicht wirklich trivial. Das ganze ist mit Sicherheit noch sehr ausbaufähig, aber erstmal funktional.

Aufgabenstellung:
Das NFS Verzeichnis nextcloud-dmz soll auf dem Proxmox-Host und gleichnamig in dem LXC Container eingebunden werden.
Beispielparameter: Container mit ID 203 und eine NAS mit der IP 192.168.30.1 und der vorhandenen Freigabe nextcloud-dmz (Squash: keine Zuodnung)

Schritt 1: Installation und Parametrierung von autofs auf dem Proxmox Host
[1] Das Paket autofs installieren
apt-get install autofs
[2] Ein Verzeichnis zum Einhängen des NFS Shares erzeugen
mkdir -p /mnt/bindmounts/
[3] Die Konfigurationsdatei auto.master parametrieren
nano /etc/auto.master

Am Ende folgendes Einfügen:
/mnt/bindmounts /etc/auto.nfs

[4] Die Konfigurationsdatei auto.nfs parametrieren
nano /etc/auto.nfs

Folgendes einfügen:
nextcloud-dmz 192.168.30.1:/volume1/nextcloud-dmz

[5] Den Dienst autofs neu starten um die Parametrierung zu übernehmen
service autofs reload

[6] Eine leere Datei erzeugen um den Zugriff zu testen
touch /mnt/bindmounts/nextcloud-dmz/test.txt

[7] ls /mnt/bindmounts/nextcloud-dmz
Kontrolle ob das File erstellt wurde
Wichtiger Hinweis: Der Mount liegt nicht dauerhaft im Verzeichnis, sondern wird immer tempörar beim Zugriff erzeugt. Siehe autofs.

Sollten das nicht funktionieren kann auf einen möglicher Fehler kontrolliert werden
[8] service autofs stop
[9] automount -f -v


Schritt 2: Den Container vorbereiten
[1] pct set 203 -mp0 /mnt/bindmounts/nextcloud-dmz,mp=/mnt/nextcloud-dmz
Bind Mount Point 0 in den LXC Container unter mnt/nextcloud-dmz mappen
[2] Den Container neu Starten damit die Konfiguration ünernommen wird
[3] Kontrolle ob das Verzeichnis existiert.

ls -al /mnt/

total 12
drwxr-xr-x 3 root root 4096 Dec 30 10:26 .
drwxr-xr-x 22 root root 4096 Dec 30 16:14 ..
d--------- 3 nobody nogroup 4096 Dec 30 15:48 nextcloud-dmz

Ein Zugriff ist zu diesem Zeitpunkt auch als root User in dem Container nicht möglich: Permission denied

Schritt 3: Mapping der User-/Group-IDs zwischen dem Proxmox Host und dem Container

[1] Auf dem Proxmox Host den Benutzer und die Gruppe 1005 anlegen
addgroup --gid 1005 nasuser
adduser --uid 1005 --gid 1005 nasuser

[2] Das Mapping zwischen dem LXC Container-User und dem User auf dem Proxmox Host herstellen

nano /etc/pve/lxc/203.conf

Am Ende der Konfiguration folgendes Mapping eintragen:

# uid map: from uid 0 map 1005 uids (in the ct) to the range starting 100000 (on the host), so 0..1004 (ct) → 100000..101004 (host)
lxc.idmap = u 0 100000 1005
lxc.idmap = g 0 100000 1005
# we map 1 uid starting from uid 1005 onto 1005, so 1005 → 1005
lxc.idmap = u 1005 1005 1
lxc.idmap = g 1005 1005 1
# we map the rest of 65535 from 1006 upto 101006, so 1006..65535 → 101006..165535
lxc.idmap = u 1006 101006 64530
lxc.idmap = g 1006 101006 64530

[3] Dem Root user auf dem Proxmox Host zusätzlich die UID 1005 hinzufügen
nano /etc/subuid

Hier die Zeile hinzufügen:
root:1005:1

[4] Dem Root user auf dem Proxmox Host zusätzlich die GUID 1005 hinzufügen
nano /etc/subgidid

Hier die Zeile hinzufügen:
root:1005:1

[5] Den LXC-Container neu starten

[6] Im Container mittels root den Zugriff auf das Share testen
Die Verzeichnisrechte sollten sich jetzt auch zum test mit:
chmod 777 /mnt/nextcloud-dmz/
ändern lassen.

stat /mnt/nextcloud-dmz/ sollte folgende Ergebnisse liefern

File: /mnt/nextcloud-dmz/
Access: (0777/drwxrwxrwx) Uid: ( 1005/ UNKNOWN) Gid: ( 1005/ UNKNOWN)

Auch wenn der User 1005 und die Gruppe 1005 in dem LXC-Container noch nicht existieren, ist jetzt überhaupt erstmals der Zugriff bei mir möglich gewesen. Sollte jetzt z.B. der User www-data der NGINX/Apache Installation im Container die UID 1005 besitzen, sollte dieser auch die entsprechenden Rechte für das Verzeichnis haben und die abgelegten Dateien sollten ebenfalls den Besitzer mit der UID/GUID 1005 haben.

Mein nächster Schritt ist jetzt das Mapping des users 33 www-data im Container (UID kann aufgrund der fertigen Installation nicht mehr geändert werden) auf die 1005 auf den Proxmox host. Ebenfalls frage ich mich ob das ganze Mapping zwischen dem Container und dem Host notwendig sind. Eigentlich solllte ja das mapping 1005 auf 1005 in der Container config ausreichen.

Ich hoffe ich habe nichts vergessen. Ich werde das ganze bei Gelegenheit im Zusammenhang mit der Nextcloud Installation noch ergänzen und weiter testen. Für jegliche Anregungen und Änderung wäre ich dankbar.

 

[mkriegl]

Hi MikeyMike,
ich stand vor einem ähnlichen Problem. Ich habe eine SSD verbaut, die ich partitioniert habe um etwa 128GB für Proxmox und die Container zu haben und der Rest ist Datenspeicher, den ich gerne auch gemeinsam nutzen will.
Gestern habe ich das Ganze dann für Nextcloud umsetzen können UID und GID 33 gemapped und schon ging es. Im ersten Anlauf hatte ich mir nur die bereits bestehende Installation was die Berechtigungen betrifft zerhauen - hätte ich vielleicht vorher anhalten sollen.
Jetzt stehe ich aber vor dem Problem Resilio Sync einzubinden - läuft in separaten Container unter dem user rslsync 998. Auf die Schnelle habe ich dem User rslsync Zugriff auf einen www-data Ordner mit >setfacl -R -m "u:rslsync:rwx" /mnt/resilio-Ordner< gegeben. Dies führt aber dazu, dass Resilio die Unterordner mit seinem eigenen User anlegt. So aktuell erstmal kein Problem, aber:
Nextcloud bietet einen Exchange-Ordner an, den ich gern mit Resilio teilen würde. AKtuell habe ich zwei drei (wie heute festgestellt) Überlegungen, wobei ich nicht sicher bin ob diese funktionieren:

1. Ich mappe für den Resilio Container die 998, wie auch schon beim Nextcloud Container die 33 und gebe dem Resilio Ordner die Rechte rslsync:rslsync statt wie bisher www-data:www-data mit der Zusatzfreigabe. Dazu wird es aber wohl zusätzlich nötig sein, den User rslsync auf dem Host anzulegen. Nextcloud wird diesen User dann aber auch benötigen, um die Freigabe auf den Exchange Ordner in Resilio machen zu können - das Ganze also umgekehrt. Probleme werde ich dann aber wahrscheinlich dabei bekommen, dass Unterordner im Resilio Exchange Ordner www-data erhalten und dann wieder nicht lesbar sind
2. Wenn ein mapping von 33 auf 33 funktioniert, sollte man doch auch ein mapping von 33 auf 998 hinbekommen, wenn ich es richtig sehe. Dann sollte der User rslsync aus dem Container auf den Ordner im Host als www-data doch ganz normal zugreifen können. Dann könnte ich mir das anlegen des Users rslsync in Host und Nextcloud sparen und wie auch Nextcloud auf die www-data Ordner zugreifen.
3. Mapping 33 für den Resilio Container beibehalten und einfach den User rslsync der Gruppe www-data mit "usermod -a -G www-data rslsync" zuweisen. Anders rum hat es irgendwie nicht funktioniert, da meckert Nextcloud

Ansonsten bin ich gerne noch für andere Ideen offen, wie man das am Besten umsetzen kann
Gruß .. Maxl

 

[mfg666]

Hallo Maxl,

könntest Du bitte Deine Änderungen in
.../lxc/*.conf
/etc/subgid
/etc/subuid
für user 33 hier posten.


... komm grad nicht weiter.

lg
mfg

 

[mkriegl]

Hi msg,

sorry für die späte Antwort. Ich habe es so umgesetzt, hat allerdings noch den Nachteil, dass Resilio weiterhin unter seinem User speichert und Nextcloud dann keine Schreibrechte hat. Den Nagel konnte ich ihm noch nicht ziehen. Dazu müsste ich allerdings glaube ich Resilio als user www-data starten.

Resilio XXX.conf:
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

subuid und subgid:
root:33:1

 

[Helmut101]

Habt ihr mittlerweile eine Lösung gefunden?

Ich bin mit einem ähnlichen Problem beschäftigt. Ich habe ein samba-share mit 8TB, was ich gern im Nextcloud LXC als read-only folder und mit bind-mount verfügbar machen möchte.

Was mir trotz sorgfältiger Lektüre der Doku nicht genau klar ist: Geht ein mapping von host-user id auf eine andere id in einem container?

z.B. samba_user (uid/gid=1005 auf host) -> www-data (uid/gid=33 im lxc)

[edit]

Lösung in der Antwort darunter aktualisiert.

 

[Helmut101]

[Edit]

Eintrag korrigiert.. ich bin in einen Bug gelaufen, der angeblich schon 2019 gefixt wurde. Das führte dazu, dass die Einstellungen in der .conf keinen Effekt mehr hatten. Im Link oben ist ein workaround beschrieben, der für mich funktioniert hat.

/etc/pve/lxc/100.conf

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

/etc/subuid

root:100000:65536
root:1005:1

/etc/subgid

root:100000:65536
root:1005:1

Auf dem host system:


Im Nextcloud container: