Hängt davon ab was du genau meinst. Das meiste wie Overhead und Passthrough etc bezog sich schon auf VMs. Datasets per Bind-Mounting in Gäste bringen geht aber in der Tat nur bei Containern.
HDD Storage Verwaltung Strategie
- Thread starter crally
- Start date
@Dunuin
Wow, vielen lieben Dank für die ausführliche und aufschlussreiche Beschreibung der Verhältnisse.
Ich hab ein bisschen Bachschmerzen an Privilegien oder User-mappings "rumzuspielen". Das trau ich mir nicht zu. ich möchte es schon so gut wie eben möglich isoliert lassen.
Ich habe nun alle Komponenten für den neuen Server da und hab heute schonmal proxmox installiert.
Zuvor hab ich folgendes gemacht:
Das Mainboard hat 2 Sata-Anschlüsse, die wohl auch 6Gb/s schnell sind. Da nur ein Stromstecker für Sata vorhanden war (eilt. für das DVD-Laufwerk), habe ich aus einem alten PC einen zusätzlichen Sata-Stromanschluss angelötet und das DVD-Laufwerk ausgesteckt.
An die beiden SATA-Anschlüsse hängen nun meine 2 Intel SSD. Die hab ich nun im Gehäuse befestigt wo Platz war.
Zudem habe ich einen geflashten Dell H310 (IT-Mode ohne BIOS), an dem nun meine HDD-Backplate hängt und ich dort meine Daten-Platten reinstecken kann.
Da ich nun zuvor noch nicht so wirklich mit ZFS zu tun hatte, habe ich mal "die Standardprozedur" durchgeführt. Also keine Advanced Einstellungen, sondern lediglich die zwei Intel SSD zu einem Mirror-ZFS gemacht.
Ich hab da jetzt quasi nur eine Partition erstellt, also hab ich im Proxmox jetzt einmal ein local(pve) und ein lokal-zfs(pve).
Dort installier ich also nun auch meine VMs/CTs.
War das ok so, oder gibts Einwände? Will jetzt von Beginn an alles "richtig" machen...
Mit dem HBA bin ich also jetzt quasi "frei". Ich kann entweder ein PCI-Passthrough machen oder eben die Platten von Proxmox managen lassen.
Ich tendiere zum PCI Passthrough nach deinen Ausführungen der Pro und Kontras.
OMV beherrscht kein ZFS, weshalb ich dann vielleicht mal trueNAS ausprobiere. Dort würde ich dann ggf. auch direkt die Nextcloud installieren, dann muss ich dort nichts per SMB o.ä. einbinden.
Da die Intel SSD's nur 400GB groß sind, würde ich dann für die "lokalen" Backups der VMs/CTs dann doch von der NAS_VM ein SMB-Share mounten, damit Proxmox darin die Backups ablegen kann. Das geschieht nur einmal wöchentlich und sollte kein Nachteil sein.
Ist der Plan so vertretbar?
Und danke nochmal an alle
Wow, vielen lieben Dank für die ausführliche und aufschlussreiche Beschreibung der Verhältnisse.
Ich hab ein bisschen Bachschmerzen an Privilegien oder User-mappings "rumzuspielen". Das trau ich mir nicht zu. ich möchte es schon so gut wie eben möglich isoliert lassen.
Ich habe nun alle Komponenten für den neuen Server da und hab heute schonmal proxmox installiert.
Zuvor hab ich folgendes gemacht:
Das Mainboard hat 2 Sata-Anschlüsse, die wohl auch 6Gb/s schnell sind. Da nur ein Stromstecker für Sata vorhanden war (eilt. für das DVD-Laufwerk), habe ich aus einem alten PC einen zusätzlichen Sata-Stromanschluss angelötet und das DVD-Laufwerk ausgesteckt.
An die beiden SATA-Anschlüsse hängen nun meine 2 Intel SSD. Die hab ich nun im Gehäuse befestigt wo Platz war.
Zudem habe ich einen geflashten Dell H310 (IT-Mode ohne BIOS), an dem nun meine HDD-Backplate hängt und ich dort meine Daten-Platten reinstecken kann.
Da ich nun zuvor noch nicht so wirklich mit ZFS zu tun hatte, habe ich mal "die Standardprozedur" durchgeführt. Also keine Advanced Einstellungen, sondern lediglich die zwei Intel SSD zu einem Mirror-ZFS gemacht.
Ich hab da jetzt quasi nur eine Partition erstellt, also hab ich im Proxmox jetzt einmal ein local(pve) und ein lokal-zfs(pve).
Dort installier ich also nun auch meine VMs/CTs.
War das ok so, oder gibts Einwände? Will jetzt von Beginn an alles "richtig" machen...
Mit dem HBA bin ich also jetzt quasi "frei". Ich kann entweder ein PCI-Passthrough machen oder eben die Platten von Proxmox managen lassen.
Ich tendiere zum PCI Passthrough nach deinen Ausführungen der Pro und Kontras.
OMV beherrscht kein ZFS, weshalb ich dann vielleicht mal trueNAS ausprobiere. Dort würde ich dann ggf. auch direkt die Nextcloud installieren, dann muss ich dort nichts per SMB o.ä. einbinden.
Da die Intel SSD's nur 400GB groß sind, würde ich dann für die "lokalen" Backups der VMs/CTs dann doch von der NAS_VM ein SMB-Share mounten, damit Proxmox darin die Backups ablegen kann. Das geschieht nur einmal wöchentlich und sollte kein Nachteil sein.
Ist der Plan so vertretbar?
Und danke nochmal an alle
Klingt soweit ok.
Ich würde da eine TrueNAS VM mit PCI Passthrough HBA echt nur als reines NAS benutzen. Nicht vergessen das TrueNAS Core ein Unix und kein Linux ist. VMs innerhalb einer VM möchte man eigentlich nicht nutzen, also müsstest du im TrueNAS die Nextcloud in einem Jail (also Unix Container) laufen lassen. Sofern du da nicht mit Unix fit bist würde ich lieber bei Linux bleiben. Außerdem verwaltet es sich viel leichter (Monitoring, Backups, Rechte, Netzwerk und so) wenn alles über Proxmox selbst läuft und du nicht Gäste in Gästen betreibst. Da würde ich Nextcloud dann schon als eigener LXC oder VM auf PVE laufen lassen und dann das Nextcloud Datenverzeichnis per NFS oder SMB in den LXC/VM bringen.
Da halte ich nicht viel von. Deine Backups sollten schon so liegen, dass man da noch drankommt, selbst wenn man die kompletten Systemplatten (also deine beiden 400GB SSD) formatieren muss oder wenn sich keine VM mehr starten lässt. Sobald dir deine beiden SSDs wegsterben laufen auch keine VMs mehr und laufen keine VMs kommst du auch nicht mehr an die SMB Shares deiner TrueNAS VM.
Die Backups würde ich schon auf eine eigene USB-HDD speichern lassen die simpel per ext4/xfs direkt an PVE angebunden ist, dass man da auch schnell wieder drankommt, selbst wenn man mal PVE komplett neu aufsetzen muss. Oder falls du noch ein externes NAS hast dann kann man die Backups natürlich noch bessert dort ablegen. Oder am allerbesten einen Proxmox Backup Server aufsetzen (tut es zur Not auch irgendein alter Rechner mit Dualcore und 2-4GB RAM).
Last edited:
Ehm... Ach ja.... ^^ Das ergibt Sinn.
Ich habe noch so eine Art Intel NUC hier rumliegen. Vielleicht werde ich den mal aufsetzen und schauen, dass ich den dann automatisiert zum Backup hochfahren lasse.
Daten auf USB spielen mach ich derzeit auch schon, allerdings von OMV aus.
Das heißt Proxmox hat via SMB ein Share meiner OMV-VM eingebunden und OMV speichert die Backups und alles Andere wiederum auf USB.
Wie gesagt....ist ein gewachsenes System, bei dem sicher noch nicht alles so durchdacht war.
Zusätzlich hab ich noch eine alte Synology, die woanders steht und sich mit meinem VPN verbindet. Allerdings war dort die Übertragungsgeschwindigkeit echt grottig (<5kB/s), weshalb ich dort schon gar nichts mehr drauf schreibe.
Ich werde mal weiter "rumspielen" und schauen, was für mich denn nun das best practice ist. Danke nochmals
Edit:
Also ich hab jetzt mal testweise OMV als VM installiert. Den HBA komplett durchgereicht. OMV-Extras und ZFS nachinstalliert. Einen Mirrored ZFS-Pool erstellt und eine SMB-Freigabe erstellt.
Der ZFS-Pool besteht aus 2x 15k SAS Platten.
SMB Übertragungsgeschwindigkeiten von/zu meinem Mac:
Lesen: 22MB/s
Schreiben 11MB/s
Alles per Gbit LAN angeschlossen... wirkt wieder sehr langsam auf mich.
Beim Lesen oder Schreiben sind die Platten aber auch nicht immer aktiv (HDD-LED am Server). Die gehen immer so für eine Sekunde an und dann ist für 3-5 Sekunden nichts.... Ist das ein zu erwartendes Testergebnis? Kommt mir sehr langsam vor.
Last edited:
Da würde ich dann mal PBS auf den NUC drauf installieren.
ZFS speichert asynchrone Writes standardmäßig nur alle 5 Sekunden. Die werden also im RAM gesammelt und dann alle 5 Sekunden auf die Laufwerke geschrieben. Deshalb verlierst du auch immer mindestens die letzten 5 Sekunden an Daten beim Stromausfall. Das die HDDs da also nur alle 5 Sekunden kurz Aktivität zeigen wäre nicht weiter verwunderlich.
Verstehe. Das ergibt ja dann Sinn. Ich hab auch gerade noch eine Ubuntu Server VM erstellt, Nextcloud installiert und dort über die "Externer Speicher" App mal das SMB-Share von OMV eingebunden. Schreibrate war noch nicht so super. Aber der download (also Leserate) war zumindest mal knapp 50 MB/s.
Ich schau mal, ob ich da noch was optimiert bekomme. Ggf. mal beiden VMs eine zusätzliche NIC zuordnen und NFS versuchen
Ich schau mal, ob ich da noch was optimiert bekomme. Ggf. mal beiden VMs eine zusätzliche NIC zuordnen und NFS versuchen
Ich hatte am Wochenende mal diverses getestet.
1. OMV in VM. Hier mag ich die Tatsache nicht, dass ich ein ZFS habe, ein Disk erstelle, diese dann in OMV als ext formatiere und dort dann die Daten schreibe. Die Schreibgeschwindigkeit war aber nie konsistent. Die schwankte zuwischen 90 und 25 MB. Jedoch allein der Overhead macht mir irgendwie ein ungutes Gefühl.
2. LXC, Debian 10, privilegiert. Hier kann ich zwar per Bind-Mount toll auf das Datasets zugreifen. Dafür gibt es auf dem Gastsystem selber an allen Ecken und Enden Probleme mit rechten. Weil dann z.B. "Besitzer" und "Gruppe" nicht root ist sondern 100000 Was ja der Root vom Host ist.
Hier habe ich am Wochenende nichts gefunden wie man das einfach und schnell regeln kann. Und wenn ich ein "chown" macht und wieder root setze ... ja das ist ja mal am Ziel vorbei würde ich sagen.
3. LXC, Debian 10 und 11, unprivilegiert. Hier läuft der Gast sauber. Dataset wird auch gemountet, aber hat natürlich keine Rechte. Das mit dem Mapping habe ich nicht ganz durchschaut auf der Proxmoxseite. Vielleicht finde ich noch eine bessere Anleitung im Netz.
Fazit:
- VM ist ganz raus.
- privilegiert wäre ok wenn man das Gastsysten sauber zum laufen bekäme. Hier fehlt mir aber der Weg. Habe keine Idee wie man das hinbekommen könnte.
- unprivilegiert wäre auch ok, und in unserem kleinen Heimumfeld mit maximal 5 Benutzern, denke gut zu händeln. Jedoch fehlt mir hier noch das Wissen wie das mit dem Mapping genau funktioniert.
Aktueller Test-Status:
LXC, Debian 11, OMV 6, unprivilegiert
1. OMV in VM. Hier mag ich die Tatsache nicht, dass ich ein ZFS habe, ein Disk erstelle, diese dann in OMV als ext formatiere und dort dann die Daten schreibe. Die Schreibgeschwindigkeit war aber nie konsistent. Die schwankte zuwischen 90 und 25 MB. Jedoch allein der Overhead macht mir irgendwie ein ungutes Gefühl.
2. LXC, Debian 10, privilegiert. Hier kann ich zwar per Bind-Mount toll auf das Datasets zugreifen. Dafür gibt es auf dem Gastsystem selber an allen Ecken und Enden Probleme mit rechten. Weil dann z.B. "Besitzer" und "Gruppe" nicht root ist sondern 100000 Was ja der Root vom Host ist.
Hier habe ich am Wochenende nichts gefunden wie man das einfach und schnell regeln kann. Und wenn ich ein "chown" macht und wieder root setze ... ja das ist ja mal am Ziel vorbei würde ich sagen.
3. LXC, Debian 10 und 11, unprivilegiert. Hier läuft der Gast sauber. Dataset wird auch gemountet, aber hat natürlich keine Rechte. Das mit dem Mapping habe ich nicht ganz durchschaut auf der Proxmoxseite. Vielleicht finde ich noch eine bessere Anleitung im Netz.
Fazit:
- VM ist ganz raus.
- privilegiert wäre ok wenn man das Gastsysten sauber zum laufen bekäme. Hier fehlt mir aber der Weg. Habe keine Idee wie man das hinbekommen könnte.
- unprivilegiert wäre auch ok, und in unserem kleinen Heimumfeld mit maximal 5 Benutzern, denke gut zu händeln. Jedoch fehlt mir hier noch das Wissen wie das mit dem Mapping genau funktioniert.
Aktueller Test-Status:
LXC, Debian 11, OMV 6, unprivilegiert
Königsweg finde ich ist immer noch ein PCIe HBA kaufen (Dell PERC H310 gibt es gebraucht z.B. für rund 35€ und kann man dann crossflashen und bekommt so einen günstigen vollwertigen LSI 9211-8i HBA mit IT-mode wo dann 8x SATA dranpassen), den HBA per PCI passthrough in eine VM durchreichen und in der VM dann TrueNAS installieren. Dann hat man weder Virtualisierungsoverhead noch sonstige Probleme, weil das GastOS dann direkt ohne Umwege auf die physischen Laufwerke zugreifen kann. ZFS lässt man dann vom Gast regeln und Host oder andere Gäste greifen dann per NFS/SMB/iSCSI auf den ZFS pool zu. Braucht man aber natürlich ein Mainboard was einen freien elektrischen PCIe 8x Slot hat und PCI passthrough auf dem Slot unterstützt.
Bist du sicher dass das ein privilegierter LXC war? Wenn ich das richtig verstanden habe sollte ein privilegierter LXC eigentlich kein User-Remapping benutzen. Der root (UID 0) im LXC sollte dann eigentlich auch auf dem Host dein root mit UID 0 sein. Deshalb sind ja privilegierte LXCs gerade so unsicher, weil der LXC root eben nicht zu einem unprivilegierten User umgemappt wird (und der LXC root daher auf dem Host nicht UID 100000 sein sollte). Weil baut man da dann im LXC mist, dann ist man ganz schnell der echte root user vom Host.
Code:
2. LXC, Debian 10, privilegiert. Hier kann ich zwar per Bind-Mount toll auf das Datasets zugreifen. Dafür gibt es auf dem Gastsystem selber an allen Ecken und Enden Probleme mit rechten. Weil dann z.B. "Besitzer" und "Gruppe" nicht root ist sondern 100000 Was ja der Root vom Host ist.
Hier habe ich am Wochenende nichts gefunden wie man das einfach und schnell regeln kann. Und wenn ich ein "chown" macht und wieder root setze ... ja das ist ja mal am Ziel vorbei würde ich sagen.Ich habe es mehrmals ausprobiert, weil ich mich gewundert habe warum es im Gast zu problemen kommt.
Wenn ich den Haken bei "privilegiert" rausnehme habe ich die komischen 100000 nummern bei Besitzer und Gruppe anstelle von z.B. "root:root".
Das mit dem HBA ist eine gute Sache, PCIe wäre auch da und 35€ nicht viel. Leider habe ich eine recht alte Hardware i3-4170 und entsprechende MB. Zumindest der CPU hat kein VT-d. Wenn ich mich nicht irre macht das das Passthrough erst möglich.
Wenn ich den Haken bei "privilegiert" rausnehme habe ich die komischen 100000 nummern bei Besitzer und Gruppe anstelle von z.B. "root:root".
Das mit dem HBA ist eine gute Sache, PCIe wäre auch da und 35€ nicht viel. Leider habe ich eine recht alte Hardware i3-4170 und entsprechende MB. Zumindest der CPU hat kein VT-d. Wenn ich mich nicht irre macht das das Passthrough erst möglich.
Oh man... ich Depp.... war natürlich doch noch ein 100 MBit Port dazwischen.....
Also nochmal gemessen und siehe da.... 102 MByte/s schreiben und 101MByte/s lesen. ^^
Also die Konstellation funktioniert schonmal. Einziges "Problem" in Bezug auf Nextcloud:
Hab die Nextcloud nun in eine eigene VM gepackt und dann das SMB-Share über die App "External Storage" eingebunden. Funktioniert, jedoch fehlt mir dann die Einstellmöglichkeit einer Quote. Also wieviel Speicherplatz welcher Nutzer haben darf.
Also hab ich die Nextcloud (bzw. Ubuntu Server VM) nochmal neu aufgesetzt und vor der Installation von Nextcloud den Share von OMV gemountet und wollte dann bei der Installation von Nextcloud diesen gemounteten Ordner als Datenverzeichnis hinterlegen.
Dann hat Nextcloud gemeckert, dass es scheinbar keine Schreibrechte hat...
Also häng ich grade auch bei einem Rechteproblem. Muss mal schauen woran es liegt.
@Aquator
Was du aber noch nicht versucht hast ist, die einzelnen Festplatten an die VM zu reichen. Also per qm set. Wäre, wie @Dunuin ja bereits erklärt hat auch eine zumindest vertretbare Option.
Und in der VM kannst du dann dein ZFS erstellen. OMV kann das mit OMV-Extras aus. Wusste ich bis gestern nicht ^^
Da hast du das Problem. Wenn du den LXC als unprivilegierten LXC erstellt hast und dann nachträglich auf privilegiert umstellst, dann ändert PVE ja nicht die bereits bestehenden Rechte. Das was vorher als "UID 0" im unprivilegierten LXC angezeigt war gehört dann "UID 100000" weil es dann als privilegierter LXC eben kein Remapping mehr gibt. Da sieht der Gast dann also die echten Dateirechte, wie sie auch auf dem Host existieren und da gehören die Ordner ja immer noch dem alten gemappten root User. Nach einem Wechsel von unprivilegiert zu privilegiert müsstest du dann schon von wirklich allen Dateien und Ordnern die Besitzer wechseln. Also chown Befehl nutzen und alles was UID 100000 bis 165535 gehört auf UID 0 bis 65535 abändern, damit das wieder so ist wie es als unprivilegiter LXC war. Oder du erstellst den LXC gleich neu und direkt als privilegierter LXC, dann passt das auch mit den Dateirechten von Anfang an.
Last edited:
;-) Ja sowas passiert immer wieder.
Sind die ~100 MB bei dir stabil? Also auch wenn du eine, bzw mehrere, große Dateien sendest? Bei mir war bei der ersten Datei ~1GB auch 120MB am start. Dann aber schwankte es immer zwischen 90 und 25.
Leider nicht. Weil ich den Storage nicht nur für OMV nutzen möchte. Daher suche ich nach einer Lösung wo der Host das ZFS erstellt und die Gäste nur die Daten darauf ablegen. Jeder Gast soll aber seinen eigenen "sicheren Bereich" haben und nicht auf die Daten des jeweils anderen Gast zugreifen.
Daher fand ich das mit den Datasets, was wie ein Container wirkt, recht gut. Den kann man dann auch noch in der Größe erweitern wenn das mal nötig wird und das Raid erweitert wird.
Oh dann hatte ich mich falsch ausgedrückt. Natürlich habe ich NICHT nachträglich von privilegiert auf unprivilegiert gestellt, oder anders herum. Immer ein "frischer" LXC.
Dann hast du aber trotzdem nicht den Besitzer des Ordners geändert? Wenn du im privilegierten LXC siehst dass der Ordner UID 100000 gehört und nicht dann UID 0, dann solltest du mal den Ordner von UID 100000 auf UID 0 abändern. Oder am Besten garnicht erst mit root arbeiten und einen eigenen OMV User erstellen und den dann zum Eigentümer des Bind-Mounts-Ordners machen.
Last edited:
Sorry. Ich muss da was durcheinandere gebracht haben. Ich habe gerade nochmal folgendes getestet:
1. (priviligiert) unprivileged: 0, Nesting ist ja eh ausgegraut dann.
2. (unpriviligiert) unprivileged: 1, features: nesting=1
3. (unpriviligiert) unprivileged: 1, features: nesting=0
1. Hier läuft alles. Gast sieht gut aus. Zugriff auf Dataset ist ebenfalls vorhanden.
2. Hier sind "lost+found", das Dataset, "proc" und "sys" UID und GID "nogroup"
3. siehe 2.
In keiner der Fälle hatte ich diesmal was von 100000 bei UID und GID stehen. Ich frage mich was das war und wie das kam.
Wenn ich das richtig gelesen habe braucht man Nesting doch nur wenn ich in diesem LXC ebenfalls Virutalisierung betreiben möchte oder?
1. (priviligiert) unprivileged: 0, Nesting ist ja eh ausgegraut dann.
2. (unpriviligiert) unprivileged: 1, features: nesting=1
3. (unpriviligiert) unprivileged: 1, features: nesting=0
1. Hier läuft alles. Gast sieht gut aus. Zugriff auf Dataset ist ebenfalls vorhanden.
2. Hier sind "lost+found", das Dataset, "proc" und "sys" UID und GID "nogroup"
3. siehe 2.
In keiner der Fälle hatte ich diesmal was von 100000 bei UID und GID stehen. Ich frage mich was das war und wie das kam.
Wenn ich das richtig gelesen habe braucht man Nesting doch nur wenn ich in diesem LXC ebenfalls Virutalisierung betreiben möchte oder?
UID 100000 sollte man wie gesagt eigentlich nur sehen, wenn man in einem privilegierten LXC ist und dann versucht auf einen durchgereichten Ordner zuzugreifen der vorher von root in einem unprivilegierten LXC besessen wurde.
Hängt vom Gast ab. Bei PVE6 ging es noch gut ohne Nesting, aber bei PVE7 will ein Debian 11 im LXC z.B. immer ein Nesting haben, weil sonst das mit Systemd nicht mehr funktioniert. Daher ist nun seit PVE7 auch per default immer Nesting deaktiviert, was bei PVE6 noch nicht war.
Ich habe gerade nochmal einen alten Beitrag durchgelesen weil da was im Kopf hatte mit Debian 11 und priviligiert.
Bin verwirrt.
Da kam deine Antwort schon wärend ich schrieb. ;-)
Wieso genau muss man das aktivieren? Weil wenn ich den Haken bei "Unpriviliged Container" raus nehme ist "Nesting" ausgegraut. Und wenn ich dann z.B. in die conf des Containers schaue steht da auch nichts von "feature: nesting 1" oder so.
Bin verwirrt.
Da kam deine Antwort schon wärend ich schrieb. ;-)
Last edited:
Hier ist nochmal eine Erklärung: https://forum.proxmox.com/threads/l...w-login-and-apparmor-errors.93064/post-409030
Ich funk mich nochmal dazwischen, falls mal jemand auf den Thread stößt.
(ACHTUNG! Nachträglich aus der Erinnerung geschrieben! Vielleicht fehlt was, aber soll auch nur als grobe Richtung dienen)
Ich habe wie gesagt den HBA zu OMV durchgereicht. Im OMV ein SMB Share angelegt und einen Nextcloud user mit entsprechenden schreib/lese Privilegien.
Als Nextcloud Unterbau fungiert ein Ubuntu Server. VOR der eigentlichen Installation von Nextcloud hab ich nun das SMB-Share gemountet.
Code:
sudo apt-get install cifs-utils
sudo mkdir /mnt/nextcloud
sudo nano ~/.smbcredentialsIn die smbcredentials nun die Anmeldedaten für den NextcloudUser an das OMV-Share eingeben.
Code:
username=msusername
password=mspasswordAnschließend mit STRG+x und y speichern.
Code:
chmod 600 ~/.smbcredentials
sudo nano /etc/fstabDer fstab Eintrag sieht dann wie folgt aus:
Code:
//<IP-von-OMV>/<Share-Name> /mnt/nextcloud cifs credentials=/home/<user>/.smbcredentials,gid=33,uid=33,forceuid,forcegid,dir_mode=0770,file_mode=0770 0 0Wieder speichern
Code:
sudo mount -aSo hast zumindest bei mir geklappt und Nextcloud hat beim Einrichtungsassistent später keine Fehlermeldung ausgespuckt das OMV-Share ist nun mein Nextcloud Datenordner. Vergeben von entsprechenden Quota in Nextcloud nun kein Problem mehr
Das mounten klappt dann auch an allen anderen VM und/oder CTs. Lediglich gid und uid im fstab Eintrag müssen ggf. angepasst werden.
Last edited:
Hast du OMV und nextcloud als VM oder LXC laufen? Und wie sind die Langzeiterfahrungen?Ich funk mich nochmal dazwischen, falls mal jemand auf den Thread stößt.
(ACHTUNG! Nachträglich aus der Erinnerung geschrieben! Vielleicht fehlt was, aber soll auch nur als grobe Richtung dienen)
Ich habe wie gesagt den HBA zu OMV durchgereicht. Im OMV ein SMB Share angelegt und einen Nextcloud user mit entsprechenden schreib/lese Privilegien.
Als Nextcloud Unterbau fungiert ein Ubuntu Server. VOR der eigentlichen Installation von Nextcloud hab ich nun das SMB-Share gemountet.
Code:sudo apt-get install cifs-utils sudo mkdir /mnt/nextcloud sudo nano ~/.smbcredentials
In die smbcredentials nun die Anmeldedaten für den NextcloudUser an das OMV-Share eingeben.
Code:username=msusername password=mspassword
Anschließend mit STRG+x und y speichern.
Code:chmod 600 ~/.smbcredentials sudo nano /etc/fstab
Der fstab Eintrag sieht dann wie folgt aus:
Code://<IP-von-OMV>/<Share-Name> /mnt/nextcloud cifs credentials=/home/<user>/.smbcredentials,gid=33,uid=33,forceuid,forcegid,dir_mode=0770,file_mode=0770 0 0
Wieder speichern
Code:sudo mount -a
So hast zumindest bei mir geklappt und Nextcloud hat beim Einrichtungsassistent später keine Fehlermeldung ausgespuckt das OMV-Share ist nun mein Nextcloud Datenordner. Vergeben von entsprechenden Quota in Nextcloud nun kein Problem mehr
Das mounten klappt dann auch an allen anderen VM und/oder CTs. Lediglich gid und uid im fstab Eintrag müssen ggf. angepasst werden.