HomeServer - Hardwareberatung

[Tropaion]

Ich borge mir eine 240GB SSD von einem Freund aus und probiere herum bzw. richte es und kopiere es dann auf die Enterprise SSD wenn die da ist, war mein Plan.

 

[Hogan]

Geht nicht nur um die TBW alleine sondern auch um die Write Amplification und die Powerloss Protection. Die MTE220S hat wohl auch keine Powerloss Protection (wie fast alle M.2 SSDs im übrigen), kann also keine Sync Writes cachen und wird dementsprechend vermutlich eine ziemlich schlechte Write Amplification haben.
Einmal sind 2.2 PB bei 1TB Kapazität auch nicht so viel wenn man es mit Enterpise SSDs vergleicht. Für um die 120€ bekommst du z.B. auch gebrauchte Enterpise (SATA-)SSDs mit 1TB Kapazität sowie MLC Flash und die können dann 21 PB schreiben mit nur einer Write Amplification von rund Faktor 2. Schreiben kann man dann also echte 10,5 PB an Daten.
Keine Ahnung was die A2000 oder MTE220S für eine Write Amplification haben, aber wenn das z.B. Faktor 20 bei kleinen 8K Sync Writes sein sollte, dann sind die 600TB/2200TB TBW schon nach dem Schreiben von 30TB/110TB an echten Daten erreicht.

Leider gibt es keine Möglichkeit vor dem Kauf herauszufinden, wie hoch da die Write Amplification ungefähr sein würde (außer man findet Benchmarks wo das mal jemand extra getestet hat). Aber generell sollte man bei Consumer SSDs keine gute Write Amplification erwarten. Erst recht nicht, wenn kein Kondensator für die Powerloss Protection verbaut ist.

Daher kann man da leider auch schlecht einen Rat geben wieviel "TBW" man denn braucht.
Ich würde da zu einer Enterprise SSD raten und wenn man sich keine neue leisten kann und keine gebrauchte haben möchte, dann sollte man die Consumer SSDs wenigstens mal eine Woche lang mit Sync Writes testen (z.B. ZFS auf "sync=always" stellen oder ein paar Anwendungen mit MySQL Datenbanken in den VMs laufen lassen), per smartctl die SMART-Werte auslesen und die Write Amplification sowie die echten Writes des NAND-Flashs pro Tag ausrechnen. Dann kann man schön ausrechnen, ob die SSD schon nach ein paar Monaten kaputt sein würden (wäre bei meinen M.2 Samsung Evos z.B. der Fall gewesen) oder ob die ein paar Jahre halten könnten. Wenn das garnicht passt kann man die SSDs in den ersten 2 Wochen wenigstens noch zurückschicken und auf eine Enterprise SSD sparen.

Ich schreibe mit Enterprise SSDs, ZFS und ziemlich vielen Sync Writes gerade um die 20MB/s, also grob 630 TB pro Jahr (inkl. Write Amplification und Overhead). Und das sind nur 7 VMs die bei mir im privaten Homelab daheim laufen und die meiste Zeit nichts zu tun haben. So 90% der Writes sind eigentlich nur die Logs und Metrics die von Zabbix und Graylog in eine MySQL/ElasticSearch/MongoDB Datenbank geschrieben werden (also kleine Sync Writes).
Das kann also schnell ziemlich extrem werden mit SSDs, wenn man den Overhead und die Write Amplification nicht beachtet. Daher immer schön testen solange man die noch zurückgeben kann.
Mein 5x 200GB raidz1 Pool (120€) hat aber eine TBW von 21PB, weshalb das selbst bei 630 TB pro Jahr um die 33 Jahre halten sollte.

Wenn man dann noch die viel höhere Write Amplification von Consumer SSDs in betracht zieht die zusätzlich hinzukommen, würde die A2000 also bei mir nur wenige Monate halten und die MTE220S wäre dann vielleicht nach einem Jahr kaputt geschrieben.

Edit:
Mal zum Verdeutlichen was ich mit Write Amplification und Overhead meine anhand meines Servers:
1.) Alle VMs zusammen schreiben 0,25 MB/s an echten Daten im Leerlauf
2.) In der VM läuft ext4 als Dateisystem, was ein Journaling-Dateisystem ist und alles erst einmal ins Journal schreibt und später vom Journal richtig auf die Laufwerke. Hier gibt es also einen Overhead von Faktor 2 und die 0.25MB/s werden zu 0.5MB/s.
3.) Dann ist die ext4 Platte in der VM ja nur virtuell und beim Weg von der virtuellen Festplatte zum physikalischen ZFS pool gibt es noch einmal etwa ein Overhead von Faktor 10. Die 0.5MB/s, die auf die virtuelle Festplatte geschrieben werden sollen, die werden dann zu 5MB/s, die auf den ZFS pool geschrieben werden müssen. ZFS muss die Blocksize halt anpassen, erstellt extra Daten für die Parität, erstellt Prüfsummen und andere Matadaten. Das wächst dann nochmal ziemlich gut an.
4.) Sync Writes werden bei ZFS auch zuerst in das ZIL Journal geschrieben und von da aus dann auf die SSD. Da ich kein SLOG habe und das ZIL daher auf der selben SSD ist gibt es also noch einmal ein Overhead von Faktor 2 und die 5MB/s werden zu 10MB/s.
5.) Dann muss die SSD diese 10MB/s auch noch speichern und da habe ich eine Write Amplification von rund Faktor 2. Die 10MB/s werden also zu 20MB/s die wirklich auf den NAND Flash auf den SSDs geschrieben werden.

Eigentlich will ich nur 0,25MB/s Logs/Metrics schreiben aber durch den Overhead und die Write Amplification werden die 0,25MB/s an echten Daten zu 20MB/s die auf die SSDs geschrieben werden müssen. Die TBW werden also 80x schneller erreicht als man es denken würde, wenn man einfach nur anguckt was da die VMs an Daten schreiben.

Hätte ich da eine Consumer SSD die z.B. eine Write Amplification von Faktor 20 statt 2 hätte, dann würde es richtig übel werden. Die 0,25MB/s an echten Daten würden dann wegen dem Overhead zu 10 MB/s und die 10 MB/s dann durch die Write Amplification zu 200 MB/s. 200 MB/s rund um die Uhr, nur um ein paar Logs und Metrics zu speichern wären echt übel und würde die SSDs im Null-Komma-Nichts killen.

Und ja, das ist schon verdammt viel Overhead, aber ich hab schon alles so gut optimiert wie ich es konnte:
-atime wurde überall deaktiviert
-Temporäre Daten gehen direkt in die RAM-Disk
-zraidz1 statt mirrored stripe weil das Writes sparen sollte
-volblocksize der zvols wurde für den pool optimiert
-ashift des pools sollte passen
-alle Partitionen sind ausgerichtet
-alle Datenbanken cachen und wurden optimiert
-cache mode richtig gewählt

Wüsste nicht was ich da jetzt hätte besser machen sollen um den Overhead zu reduzieren.
Das ist mit der Virtualisierung und ZFS ist halt noch einmal etwas ganz anderes als man das z.B. beim normalen Windows Gaming-/Arbeits-PC hat. Hier im Server würden die Consumer SSD wie Samsung Evos nur Wochen oder Monate halten und wenn ich die in den GamingPC stecken würde, der eigentlich viel mehr schreibt, dann wären die erst nach Jahrzehnten kaputt. Da darf man also nicht auf die SSD-Abnutzung im normalen PC gucken und dann hochrechnen, was man wohl für einen Server so brauchen würde. Das ist halt überhaupt nicht vergleichbar.

Edit:
HDDs hatte ich übrigens auch versucht um das nervige Abnutzen der SSD durch Writes zu umgehen.
Klappe aber nicht, da sich durch den Overhead nicht nur die Menge an Daten vervielfacht hat, sondern auch die Zugriffe pro Sekunde. Am Ende waren das dann einige Hundert IOPS und damit waren die HDDs dann durch die vielen kleinen Schreibvorgänge hoffnungslos überfordert und die Latenz war viel zu hoch.
Da bin ich dann von Consumer M.2 SSD über NAS HDDs zu Enterprise SATA SSDs gekommen.

@Dunuin 5*200 GB im raidz1 mit 21PBW? Ich beschäftige mich mit dem Thema erst sehr kurz. Sind das dann nicht im Schnitt 4200 TBW? Welche SSDs hast du für 24€ das Stück gekauft die so eine TBW haben?

Ich möchte meine PVE Spielwiese ausbauen und bin gerade am überlegen was ich wo verwende.
Siehe hier

 

[Dunuin]

@Dunuin 5*200 GB im raidz1 mit 21PBW? Ich beschäftige mich mit dem Thema erst sehr kurz. Sind das dann nicht im Schnitt 4200 TBW? Welche SSDs hast du für 24€ das Stück gekauft die so eine TBW haben?

Ich möchte meine PVE Spielwiese ausbauen und bin gerade am überlegen was ich wo verwende.
Siehe hier

Ich hab 5x Intel S3710 200GB als Raid5 für zusammen rund 165€ gekauft. Die haben jeweils laut Datenblatt:

Bewertung der Ausdauer (lebenslange Schreibzugriffe)
3.6PB

Mittlere Betriebsdauer bis zum Ausfall (MTBF)
2,000,000 hrs

Uncorrectable Bit Error Rate (UBER, nicht korrigierbare Bitfehlerrate)
10^17

Garantiezeit
5 yrs

Also je SSD 3600 TBW und in der Summe dann 18 PB und nicht 21 PB. Bin ich wohl durcheinander gekommen und hatte noch die TBW meiner Systemplatten (2x Intel S3700 100GB mit je 1800 TBW) mit im Kopf. Zusammen wären dann alle meine 7 SSDs grob 21 PB als TBW.

Bei den 125€ je TB hatte ich mit Intel DC S3710 400GB gerechnet. Da hatte ich mir 3 Stück für je 50€ für mein NAS gekauft. Also 150€ für 1200GB, was dann 125€ pro TB entspricht. So eine S3700/S3710 mit 400GB hätte 7200 TBW.

 

[Hogan]

Ich hab 5x Intel S3710 200GB als Raid5 für zusammen rund 165€ gekauft. Die haben jeweils laut Datenblatt:

Also je SSD 3600 TBW und in der Summe dann 18 PB und nicht 21 PB. Bin ich wohl durcheinander gekommen und hatte noch die TBW meiner Systemplatten (2x Intel S3700 100GB mit je 1800 TBW) mit im Kopf. Zusammen wären dann alle meine 7 SSDs grob 21 PB als TBW.

Bei den 125€ je TB hatte ich mit Intel DC S3710 400GB gerechnet. Da hatte ich mir 3 Stück für je 50€ für mein NAS gekauft. Also 150€ für 1200GB, was dann 125€ pro TB entspricht. So eine S3700/S3710 mit 400GB hätte 7200 TBW.

Danke für die Erläuterung! Das war sehr hilfreich! Ich hatte bisher nur die Intel S35er Serie auf dem Schirm. bin da bzgl. solcher Fragestellungen noch nicht so firm. Die S37er Serie sieht wirklich interessant aus!

Frage: Ist das ein RAID5 (HW-Controller) oder ein RAIDZ5?
ist RAIDz1 eine alternative?

 

[Dunuin]

Ich habe raidz1 benutzt was quasi das ZFS Gegenstück von Raid5 ist. Also 4 von 5 SDDs sind dann von der Kapazität her nutzbar. Leseleistung sollte grob der 4 oder 5 fachen Leseleistung einer einzelnen SSD entsprechen und Schreibleistung ca. das was eine einzelne SSD schafft. Eine SSD darf dann ausfallen. Man muss die optimale Volblocksize allerdings ausrechnen und einstellen, sonst sieht das zwar aus, als ob man 80% der Gesamtkapazität nutzen könnte aber alles nimmt mehr Platz ein als nötig, weshalb das dann indirekt auch nicht mehr effektive Kapazität wie ein Mirror/Raid1 liefern würde.

Bei ZFS darf man dann auch kein HW-Raid-Controller benutzen bzw muss dieser in den IT-Mode geflasht werden, damit der ohne RAID arbeitet. Um Raid kümmert sich dann ZFS per Software.

 

[Tropaion]

@Dunuin
Ich bin es wieder mal. Ich hab jetzt meine ProxMox-Config aufgesetzt und TrueNAS (mit 16GB RAM aktuell) installiert.
PCIe-Passthrough war bisschen problematisch aber jetzt geht es.

Ich habe jetzt 4x3TB HDDs am HBA und schwanke zwischen RAIDZ und RAIDZ2, das gibt es so viele Diskussionen darüber...
Was würdest du empfehlen?

 

[Dunuin]

Generell sagt man für raidz1 sollte man eine ungerade Zahl an Festplatten nehmen und für raidz2 eine gerade. Also 3, 5 oder 7 HDDs für raidz1 und 6 oder 8 HDDs für raidz2. Muss man nicht zwingend nutzen (ich habe auch nur 4x 8TB als raidz1 im NAS da für mehr das Geld nicht reichte) aber dann leidet halt etwas die Performance.
Raidz2 mit nur 4 HDD wäre ziemlich sinnlos, da du dann ja nur die Kapazität von 2 von 4 HDDs effektiv nutzen kannst was dann so verschwenderisch wie ein Mirror wäre. Ein Mirror wäre da dann aber deutlich schneller, es dürften aber wie beim raidz1 nicht 2 HDDs gleichzeitig ausfallen.

Ob man Raidz1 oder Raidz2 nutzen will hängt auch ein bisschen davon ab, wie groß die HDDs sind. Sollte mal eine der HDDs ausfallen passiert erst einmal überhaupt nichts und alles läuft normal weiter und man verliert nichts. Dann muss man aber erst eine neue HDD nachkaufen was ein paar Tage dauern kann und anschließend muss man den Pool resilvern. Das Resilvern kann je nach Poolgröße auch einige Tage dauern und dabei sind die HDDs dann unter permanenter Auslastung. Wenn die HDDs dann noch alle etwa gleich abgenutzt sind steigt die Chance, dass da unter der Last dann noch eine zweite HDD ausfällt. In dem Fall wären dann bei raidz1 alle Daten im Pool verloren.
Bei raidz2 verlierst du eine weitere Platte an Kapazität, dafür dürfen dann aber gleichzeitig 2 HDDs ausfallen.

Mir persönlich reicht da bei 4 HDDs raidz1. Ist zwar etwas riskanter aber Raid sollte ja eh keine Backups ersetzen. Wenn man also eh Backups von allem Wichtigem haben sollte, dann ist auch der recht unwahrscheinliche Fall, dass da 2 HDDs gleichzeitig ausfallen, verkraftbar.
Später hatte ich mir nochmal die gleichen Festplatten gekauft. Also 4x 8TB als raidz1 im HauptNAS und dann nochmal 4x 8TB als raidz1 im BackupNAS. Und einmal die Woche repliziere ich dann alle Daten vom HauptNAS zum BackupNAS.

Ich persönlich würde da bei 4x 3TB einfach raidz1 nehmen. Dann kannst du 9TB effektiv nutzen und da der Pool recht klein ist sollte das Resilvern auch nicht sooo lange dauern. Wenn du keine anderen Festplatten für Backups hast, dann wäre es vielleicht noch eine Idee nur 3x 3TB als Raidz1 zu nutzen + 1x 3TB für Backups. Dann könntest du 6TB ausfallsicher nutzen und hättest noch 3TB für Backups.

Falls du irgendwann mal Geld für eine 5te HDD hättest wären auch 3x 3TB als raidz1 + 2x 3TB als zfs stripe eine gute Idee. Du hast ja eh Platz für 8 Hotswap-Plätze. Dann könntest du den 6TB Haupt-Pool (3x 3TB als raidz1) immer im Server lassen. Einmal im Monat oder so steckst du die beiden Backup-HDDs dann per Hotswap in den Server, Importierst den 6TB Backup-Pool (2x 3TB als zfs stripe), replizierst alles vom Haupt-Pool auf den Backup-Pool, exportierst den Backup-Pool und entfernst die beiden Backup-HDDs wieder, um die an einem anderen Ort (Familie, Arbeit, Keller etc) sicher zu lagern. Das fänd ich noch die eleganteste Lösung, da du so wirklich alles doppelt hast. Ein Offline-Backup das nicht am gleichen Ort ist, sollte man ja eigentlich eh immer nutzen. Dann ist man auch sicher vor Bränden, Einbrüchen, Stromschlägen, Wasserschäden, Ransomware, abrauchenden Netzteilen, Software-Bugs und wenn mehr als 1 HDD im raidz1 ausfällt wäre es dann auch egal, da alles noch 1-zu-1 sicher auf dem Backup liegt.

 

[Tropaion]

@Dunuin
Danke für die Info, hab das jetzt so eingerichtet.
Leider ist wieder ein weiter Problem aufgetreten. Ich hab jetzt einen BackUp Job auf NFS-Share von FreeNAS eingerichtet, aber leider schlagen alle LXC-BackUps fehl. (VM BackUp funktioniert).
Hier die Fehlerausgabe:

INFO: starting new backup job: vzdump --mailnotification failure --mode snapshot --quiet 1 --node ve --mailto f.plaimauer@gmail.com --exclude 101 --storage nas-backup --all 1 --compress zstd
INFO: Starting Backup of VM 100 (lxc)
INFO: Backup started at 2020-11-05 16:31:24
INFO: status = running
INFO: CT Name: ReverseProxy
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
INFO: creating vzdump archive '/mnt/pve/nas-backup/dump/vzdump-lxc-100-2020_11_05-16_31_24.tar.zst'
INFO: tar: /mnt/pve/nas-backup/dump/vzdump-lxc-100-2020_11_05-16_31_24.tmp: Cannot open: Permission denied
INFO: tar: Error is not recoverable: exiting now
INFO: remove vzdump snapshot
ERROR: Backup of VM 100 failed - command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/mnt/pve/nas-backup/dump/vzdump-lxc-100-2020_11_05-16_31_24.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/mnt/pve/nas-backup/dump/vzdump-lxc-100-2020_11_05-16_31_24.tar.dat' failed: exit code 2
INFO: Failed at 2020-11-05 16:31:24
INFO: Starting Backup of VM 102 (lxc)
INFO: Backup started at 2020-11-05 16:31:24
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: CT Name: NextCloud
INFO: including mount point rootfs ('/') in backup
INFO: creating vzdump archive '/mnt/pve/nas-backup/dump/vzdump-lxc-102-2020_11_05-16_31_24.tar.zst'
INFO: tar: /mnt/pve/nas-backup/dump/vzdump-lxc-102-2020_11_05-16_31_24.tmp: Cannot open: Permission denied
INFO: tar: Error is not recoverable: exiting now
ERROR: Backup of VM 102 failed - command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/mnt/pve/nas-backup/dump/vzdump-lxc-102-2020_11_05-16_31_24.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/mnt/pve/nas-backup/dump/vzdump-lxc-102-2020_11_05-16_31_24.tar.dat' failed: exit code 2
INFO: Failed at 2020-11-05 16:31:24
INFO: Starting Backup of VM 103 (qemu)
INFO: Backup started at 2020-11-05 16:31:24
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: VM Name: FHEM
INFO: include disk 'scsi0' 'local-zfs:vm-103-disk-0' 32G
INFO: snapshots found (not included into backup)
INFO: creating vzdump archive '/mnt/pve/nas-backup/dump/vzdump-qemu-103-2020_11_05-16_31_24.vma.zst'
INFO: starting kvm to execute backup task
INFO: started backup task '2b64f932-a2e5-4b7b-8432-9cffd6baeaea'
INFO:   1% (442.2 MiB of 32.0 GiB) in  3s, read: 147.4 MiB/s, write: 86.7 MiB/s
------- AUSGESCHNITTENER TEIL -------
INFO:  97% (31.3 GiB of 32.0 GiB) in  1m 23s, read: 532.4 MiB/s, write: 92.0 KiB/s
INFO: 100% (32.0 GiB of 32.0 GiB) in  1m 25s, read: 383.7 MiB/s, write: 0 B/s
INFO: backup is sparse: 29.57 GiB (92%) total zero data
INFO: transferred 32.00 GiB in 85 seconds (385.5 MiB/s)
INFO: stopping kvm after backup task
INFO: archive file size: 836MB
INFO: Finished Backup of VM 103 (00:01:28)
INFO: Backup finished at 2020-11-05 16:32:52
INFO: Backup job finished with errors
TASK ERROR: job errors

 

[Dunuin]

Sieht so aus als wenn du keine Schreibrechte auf deinem auf dem NFS-Share hast. Anders als bei SMB gelten da bei NFS die gleichen Rechte zwischen Client und Host. Also wenn ein User auf dem Client mit der UID 1000 (z.B. der Proxmox User der Backups machen will) auf das NFS share zugreift, dann muss da ein User mit der UID 1000 auf FreeNAS auch die Rechte für den Share haben.

Ich habe mir dafür in FreeNAS einen "proxmox" user angelegt, den als Eigentümer des Datasets gesetzt, welches ich per NFS als Netzwerk-Share bereitstellen und bei den NFS-Share-Einstellungen in FreeNAS habe ich dann "mapalluser=proxmox" und "mapallgroup=proxmox" angegeben. Damit wird dann jeder Zugriff auf den Share so ausgeführt, als wäre es der User "proxmox" mit der Gruppe "proxmox" wäre und da diesem das Dataset gehört, hat dieser auch volle Rechte.

Aber nicht vergessen dann auch in FreeNAS bei dem Share etwas für "Authorized Networks" und "Authorized Hosts" zu setzen, da bei NFS in der Grundeinstellung keinerlei Authentifizierung stattfindet und jeder im Netzwerk dann als User "proxmox" ohne Passwortabfrage volle Rechte für den Share hat. Man kann prinzipiell Kerberos verwenden, um NFS mit Authentifizierung zu nutzen, aber das wird ziemlich kompliziert.

Edit:
Ah, vergiss was ich oben geschrieben habe. Hab übersehen, dass das für VMs läuft nur für LXC nicht. Dann klappt das ja prinzipiell bei dir mit den Rechten auf dem NAS. Mit LXC hatte ich auch erst zu kämpfen. Wenn dein LXC unprivilegiert ist, dann darf der Nichts mounten. Also auch keine NFS-Shares.
Da musst du dann den NFS-Share direkt in Proxmox selbst mounten (habe ich bei Proxmox einen Eintrag in "/etc/fstab" gemacht) und den Mount-Pfad dann von Proxmox in den LXC durchreichen (LXC -> Ressources -> Add -> Mountpoint). Und dann musst du das Mapping der User und Gruppen noch anpassen. Guck mal hier: https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

Edit:
Bei mir sieht das etwa so aus...

1.) User "pmxshare" und Gruppe "pmxshare" mit UID 1100 und GID 1100 in TrueNAS anlegen.
2.) Dataset (z.B. DeinPool/ProxmoxShare) in TrueNAS erstellen und ACLs und Rechte so vergeben, dass da User+Gruppe "pmxshare" der Besitzer ist
3.) NFS Share für das Dataset anlegen. User "pmxshare" als "Mapall User" und Gruppe "pmxshare" als "Mapall Group" angeben. Bei "Authorized Hosts" die IP des Proxmox-Containers angeben, damit nur diese Zugriff auf den Share erhält.
4.) User "pmxshare" und Gruppe "pmxshare" in Proxmox erstellen (mit "adduser" per cli und den User dann per GUI in Proxmox eintragen). Dabei darauf achten, dass da UID und GID ebenfalls 1100 sind.
5.) NFS Share per fstab in Proxmox mounten. Z.B. nach "/mnt/ProxmoxShare".
6.) Im LXC einen leeren Ordner als Mountpoint erstellen der root gehört. Z.B. "/Pfad/Zu/Deinem/LXCRoot/media/ProxmoxShare".
7.) Im LXC einen User "pmxshare" und eine Gruppe "pmxshare" mit UID 1100 und GID 1100 erstellen
8.) Die Config-Datei deines LXCs editieren. Wäre z.B. "/etc/pve/lxc/100.conf" wenn der LXC die ID "100" hat.
Dort dies einfügen um einen Bind-Mount des Ordners "/mnt/ProxmoxShare" vom Proxmox-Host zum Ordner "/media/ProxmoxShare" (relativ zum LXC root) des LXC zu erstellen:
mp0: /mnt/ProxmoxShare,mp=/media/ProxmoxShare
Alle UID und GIDs im LXC werden random umgemappt. Wenn du einen "pmxshare" User im LXC mit der UID "1100" im LXC erstellen würdest, dann hätte der zwar im LXC die UID 1100 aber auf dem Proxmox-Host selbst würde es z.B. zu UID 123456 gemappt werden und UID 123456 hätte dann wohl kein Zugriff auf deinen Share, wo z.B. nur der User mit der UID 1100 rauf darf. Da muss man dann das Mapping manuell ändern, dass da der User mit der UID 1100 innerhalb des LXC ebenfalls die UID 1100 auf dem Proxmox-Host hat. Dazu gibt man dann folgendes ein:
lxc.idmap = u 0 100000 1100
lxc.idmap = g 0 100000 1100
lxc.idmap = u 1100 1100 1
lxc.idmap = g 1100 1100 1
lxc.idmap = u 1101 101101 64435
lxc.idmap = g 1101 101101 64435
Das besagt quasi, dass da von UID/GID 0 bis 1099 auf 100000 bis 100099 gemappt wird, sowie alles von UID/GID 1101 bis 65565 auf 101101 bis 165565. Nur die UID/GID 1100 wird auf 1100 gemappt und bleibt dann gleich.

Dann muss man noch die Dateien "/etc/subuid" und "/etc/subgid" auf dem Proxmox-Host anpassen und dort jeweils "root:1100:1" einfügen um das Mappen zu erlauben.

So geht das dann auch mit SMB-Shares, wenn man die mit UID 1100 und GID 1100 auf dem Proxmox-Host einbindet.

Ich finde das leider alles unglaublich umständlich. Und die Abhängigkeit zwischen Host und LXC kann dann irgendwann auch wieder nerven, wenn da alles voneinander abhängt. Bisher habe ich deshalb auch nur 2 LXCs für meine Docker-Container am laufen und alles andere läuft in VMs, auch wenn die VMs eigentlich zu verschwenderisch sind und es ein LXC auch tun würde.