OS für All-In-One Server?

Bzgl. TrueNas lese ich immer davon, dass man es auf einem SSD mirror installiert, ist das eine Notwendigkeit oder eher halt "Best Practice"?
Wird empfohlen im Forum.
In dem Forum wo Leute Systeme mit Dual socket Epic und 24-36 Platten betreiben.
Wieso? Weil wenn eine SSD aussteigt das System mit 0 Downtime weiter läuft. Was für Enterprise Level wichtig ist.
Wenn Privat eine system SSD aussteigt musst du einfach eine neue einbauen, Frisch installieren und config Datei neu laden. Dann läuft wieder alles.
Es gibt Scripte die die Config Datei automatisch abspeichern, via ftp oder Email.. . Alles.
Und ich glaub mit IX account kann man sie sogar direkt in deren cloud speichern?

Was mich dann aber schon etwas stört, was ich hier gelesen habe, kann ich unter TrueNas nicht einen SMB Share in einer Docker Container mounten? Das hab ich bei dem ein oder anderen Container (z.B. paperless ingest) aktuell aufm QNAP schon so gemacht... oder verstehe ich da das „hostPathValidation” Thema falsch?
Thema veraltet.
Wie so gut wie immer alles wo man Tutorials zu TrueNAS findet -.-
Seit nicht mehr kubernetes sondern Docker als APPs laufen kann man einfach ganz normal einen Pfad Mounten.

Btw ich hab TrueNAS baremetall und eine HAOS VM, der ganze rest läuft einfach in Docker/Apps.
Backups Gehen ganz bequem, mit Snapshots, über replication.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Neuerdings könnte man auch mal TrueNAS als container probieren: https://www.truenas.com/docs/scale/25.04/scaletutorials/containers/
Edit: Hab das wohl missverstanden - hier geht es um Container-Support UNTER TrueNAS, nicht TrueNAS IM Container
Hab ich noch nicht getestet, aber das könnte deutlich resourcenschonender sein, als ne Extra VM und man muss nur noch den Storage-Pool in Proxmox verwalten, wenn man keinen extra controller möchte und diesen dann in den Container durchmounten um einfaches Freigabenmanagement zu haben.

Ich persönlich hab schon viel ausprobiert und bin am Ende auch bei Proxmox gelandet. Storage konfiguriert man üblicherweise nicht so häufig, aber Virtualisierung und Systemmanagement braucht man regelmäßig, daher war mir der Zusatzaufwand für das Storagemanagement auf der Konsole lieber, als jeden Tag mit TrueNAS VM-Gefrickel zu haben.

Dennoch: Proxmox hat ne steile Lernkurve und wenn man schnell fertig werden will, sollte man sich das gut überlegen.
Puh, also nur fürs Storagemgmt so einen Aufriss machen ? Dann wie du sagst lieber per CLI oder napp-it CS installieren
 
Man <kann> auch ganz stumpf eine WIndows VM aufsetzen, Platten druchreichen und eine Windows SMB Freigabe machen. Jeder nach seinen Skills ;)
 
Windows als SMB Filer ist nicht ohne, bietet bei Weitem die beste ACL Unterstützung, kann Gruppen in Gruppen, oder virtual harddisks .vhdx sogar über SMB, dazu Storage Spaces für Pools unterschiedlich großer und schneller Platten mit auto tiering für ntfs oder ReFS. OpenZFS für normales Software Raid ist auch fast fertig. In der Server (Essentials) gibts dann zusätzlich AD und SMB Direct/RDMA.

Da stellt sich aber schnell die Frage ob man AiO nicht auch gleich mit Windows + Hyper-V machen könnte wenn man primär einen SMB Filer braucht..
 
(...), kann Gruppen in Gruppen (...)

Hi @gea
Wie ist das gemeint? Kann der Omnios SMB das nicht? Oder NFSv4 ACLs? Ich überlege gerade auf ein anderes Storage als Windows zu wechseln, aber das nutzt unser bisheriger Filer... Viel. Sagen wir es wird viel genutzt.
Aber das Gruppen in Gruppen eine Einschränkung sein kann hab ich in meinen Überlegungen noch gar nicht bedacht?
 
Hi @gea
Wie ist das gemeint? Kann der Omnios SMB das nicht? Oder NFSv4 ACLs? Ich überlege gerade auf ein anderes Storage als Windows zu wechseln, aber das nutzt unser bisheriger Filer... Viel. Sagen wir es wird viel genutzt.
Aber das Gruppen in Gruppen eine Einschränkung sein kann hab ich in meinen Überlegungen noch gar nicht bedacht?

Der Kernel Solaris/OmniOS SMB Server nutzt ntfs artige NFSv4 ACL, kann Gruppen in Gruppen und benutzt Windows SID als ACL Datei Referenz in ZFS.
Hier gehts aber um Proxmox/Linux und da gibts das nicht.
 
Ah okay, dann weiß ich jetzt was du meinst.
Weißt du wie das unter TrueNAS ist? Das bietet ja jetzt über nfs4 ACLs ja auch Windows-like ACLs an
 
Free-BSD unterstützt NFSv4 ACL, Linux bisher nur simple Posix Acl. Da gibt es zwar auch Entwicklungen in Linux und SAMBA aber im Moment ist das keine Option. TN hat beim Portieren von core auf scale versucht NFSv4 ACL "dranzubasteln". Solange Linux selbst aber keine generellen NFSv4 ACL unterstützt, bleibt das Stückwerk und macht alles eigentlich nur inkompatibel, kompliziert und fehleranfällig. Gruppen in Gruppen und Windows SID als Dateireferenz gibts ohnehin nur in Illumos/Solaris/Windows.

 
Puh, also nur fürs Storagemgmt so einen Aufriss machen ? Dann wie du sagst lieber per CLI oder napp-it CS installieren
Ich mach das ganz anders, aber das ist gar nicht so empfohlen, daher werde ich das hier nicht breit treten ;)
Puh, also nur fürs Storagemgmt so einen Aufriss machen ? Dann wie du sagst lieber per CLI oder napp-it CS installieren
Ich persönlich plane, demnächst mal die zamba toolbox auszuprobieren: https://git.bashclub.org/bashclub/zamba-lxc-toolbox, genauer den zmb-standalone.

Die Configs sind sehr interessant, da die auch ein Einbinden des SMB mit Dateiversionierung via zfs-auto-snapshot in Windows ermöglichen (man kann also per "Rechtsklick" Dateien zurückrollen), das ist für Windows User sicherlich nicht uninteressant.
Also man mounted quasi via SMB unter Windows und kann als Client auf dem Server Dateiversionierung betreiben - über die native Windows GUI dafür. Im Hintergrund werden dann ZFS-Snapshots zurück gerollt.

Mehr dazu hier: https://aow.de/books/lxc-toolbox-fur-proxmox/page/zamba-fileserver

Ich denke besonders cool wäre es, wenn man in diesen LXC-Container beliebigen (externen) Storage per map/mount so nutzen könnte und der LXC container quasi nur den Service bereit stellt - womit dann auch keine festgelegte Größe (z.B. 100GB) mehr nötig wäre, sondern er einfach die größe nimmt, die man reinmounted.
 
Zuletzt bearbeitet:
In der Diskussion wird die Umgebung, in der der Server bzw. SMB eingesetzt werden soll, bislang nicht berücksichtigt. Für mich ist Windows beispielsweise irrelevant, da ich es privat nicht nutze. Bei mir kommt vorwiegend macOS aber auch Linux zum Einsatz. In der Apple-eigenen SMB-Implementierung gibt es leider einige Besonderheiten. Samba verfügt mit vfs_fruit über ein Modul, das diese Apple-Besonderheiten größtenteils nachbildet. Meines Wissens haben andere SMB-Server nichts Vergleichbares für macOS in diesem Umfang implementiert.
Wer den SMB-Server in einer Windows-Umgebung einsetzt, hat daher durchaus andere Anforderungen als Jemand, der Macs einsetzt.
macOS kann NFS4 ACLs und zieht diese wohl auch POSIX ACLs vor. Ich habe mich damit allerdings nicht wirklich befasst.

Zu den Besonderheiten von macOS. Manches muss vielleicht wegen macOS so sein, anderes ist unnötig und einfach nur ärgerlich:
Bzgl. Server-Side Copy hat man in TrueNAS Scale allerdings einen eigenen Patch entwickelt, der anders als das entsprechende Setting in vfs_fruit funktioniert. macOS scheint sich bzgl. IOCTL-Anfragen anders zu verhalten, als es das SMB-Protokoll vorsieht.
 
Man muss bei den ACL immer unterscheiden, ob man das aus Sicht des Dateisystems betrachtet oder aus Sicht des SMB Nutzers und da ist es egal welches Client OS benutzt wird. So kann man selbst mit SAMBA unter einem Posix Linux weitgehend die Windows ntfs ACL nachbilden. Das setzt SAMBA um. Mangels Unterstützung des Dateisystems ist das aber sehr fehleranfällig und mit viel smb.conf Tuning verbunden, benötigt dazu mapping uid->SID und geht teils nur im AD Modus gut.

z.B.
Wenn man aus Linux oder OSX auf einen Windows oder OmniOS SMB Server zugreift, so hat man keine Option die Windows SMB Rechte und User remote sauber zu sehen oder zu bearbeiten. Man muss die dann lokal auf dem SMB Server oder remote von einem Windows Rechner setzen. Sie werden jedoch beachtet. Wenn man z.B. kein ACL Recht hat einen Ordner anzulegen, so gibts beim Versuch halt "Access Denied".

Für OSX mit SAMBA sollte man die smb.conf manuell anpassen. Da soll es in TN Probleme geben, nutze ich selber nicht

Bei OmniOS sind die OSX Anpassungen im kernel SMB Server enthalten, auch um Bonjour und Timemachine über SMB zu unterstützen.
 
Hat man mit Windows als Storageserver nicht ein Lizenzproblem? So weit ich weiss, darf man ein "normales" Widows nicht als Server missbrauchen, und bei Serverversionen braucht mal CALs.
 
Hat man mit Windows als Storageserver nicht ein Lizenzproblem? So weit ich weiss, darf man ein "normales" Widows nicht als Server missbrauchen, und bei Serverversionen braucht mal CALs.

Nö, ein normales Windows 11 kann problemlos SMB Server sein, die Anzahl der gleichzeitig möglichen SMB Sitzungen ist aber auf 20 begrenzt. Diese Grenze gibt es bei Windows Server nicht. Bei den Server Lizenzen gibt es die günstige Essentials, da braucht man keine Cals wenn die Anzahl der Nutzer <=25, die Anzahl der Geräte <=50 ist und die single CPU max 10 Cores hat und der RAM <=128GB ist. Das ist vor allem mit SMB Direct/rdma interessant weil man da die Server Edition braucht.

Überschreitet man das oder braucht man mehrere Windows Server muss man die normalen Windows Server mit Cals lizenzieren.
Auch darf man die Essentials nur entweder auf Hardware installieren oder virtualisieren, nicht beides gleichzeitig.
 
Zuletzt bearbeitet:
Wer zu Hause für ein paar Leute einfach nur wie beim NAS ein paar Freigaben braucht, und mit SMB auskommt, für den ist eine WIndwos Instanz als Filer durchaus eine Option.
 
Man muss bei den ACL immer unterscheiden, ob man das aus Sicht des Dateisystems betrachtet oder aus Sicht des SMB Nutzers und da ist es egal welches Client OS benutzt wird. So kann man selbst mit SAMBA unter einem Posix Linux weitgehend die Windows ntfs ACL nachbilden. Das setzt SAMBA um. Mangels Unterstützung des Dateisystems ist das aber sehr fehleranfällig und mit viel smb.conf Tuning verbunden, benötigt dazu mapping uid->SID und geht teils nur im AD Modus gut.
Ja, das ist mir klar geworden. Eine SID, die zudem noch „Windows-kompatibel” ist, hat hier klare Vorteile.
z.B.
Wenn man aus Linux oder OSX auf einen Windows oder OmniOS SMB Server zugreift, so hat man keine Option die Windows SMB Rechte und User remote sauber zu sehen oder zu bearbeiten. Man muss die dann lokal auf dem SMB Server oder remote von einem Windows Rechner setzen. Sie werden jedoch beachtet. Wenn man z.B. kein ACL Recht hat einen Ordner anzulegen, so gibts beim Versuch halt "Access Denied".
Sicher, dass das bei macOS so ist? Ich habe mich wie gesagt damit noch nicht beschäftigt. Die macOS GUI scheint eingeschränkt zu sein. Für mehr, muss man ins Terminal oder bestimmtes Tools nutzen (ich glaube von Marcel Bresink gibt es dazu etwas).
Für OSX mit SAMBA sollte man die smb.conf manuell anpassen. Da soll es in TN Probleme geben, nutze ich selber nicht
Nicht wirklich. Man kann vorgefertigte SMB-Profile inkl. vfs_fruit in TrueNAS Scale aktivieren, mit denen macOS recht gut läuft.
Es würde aber wahrscheinlich noch besser gehen.
Dazu müsste man manuelle Anpassungen vornehmen. Dies ist aber problematisch, da TrueNAS Scale wie eine Appliance funktioniert und man Änderungen nur über die GUI vornehmen sollte. Ansonsten arbeitet man an dem System vorbei und läuft Gefahr, dass die Änderungen bei Neustarts, Upgrades, etc. überschrieben werden. Das funktioniert grundsätzlich und ist für eine Appliance auch in Ordnung bzw. passt in das Konzept. Allerdings wurden die Auxiliary Parameters für SMB, die genau solche zusätzlichen Anpassungen für SMB ermöglichen, in TrueNAS Scale mit der Version 23.10 (Cobia) entfernt.
Möglicherweise kann man einen Hack bauen, um das zu umgehen, in dem man eine smb4_custom.conf mit dem Delta zu der smb4.conf baut und diese mittels einem include (scheint unterstützt zu werden) in der automatisch generierten smb4.conf einbindet, sodass alle darin enthaltenen benutzerdefinierten Samba-Einstellungen ergänzend und updatesicher angewendet werden, ohne die Hauptkonfiguration direkt zu verändern. Ausprobiert habe ich das noch nicht.
Bei OmniOS sind die OSX Anpassungen im kernel SMB Server enthalten, auch um Bonjour und Timemachine über SMB zu unterstützen.
OK. Das ist das schon etwas und auf jedenfalls mehr als ein Windows oder ein KSMBD. vfs_fruit kann allerdings vermutlich noch mehr an macOS-Besonderheiten abbilden und kann sogar Spotlight-Integration bieten. Es ist möglich eine serverseitiges Spotlight aufzusetzen, idealerweise in Verbindung mit elasticsearch. Das wird aber bislang offenbar nur selten verwendet, da die Fertig-NAS-OS-Lösungen noch nichts fertige anbieten und man sich das selber zurechtbasteln muss. Allerdings scheint Synology und evtl. auch QNAP das ebenfalls zu können, wobei die das dann ggf. über eigene Lösungen implementiert haben.
Ich finde Solaris ja grundsätzlich toll. Solaris war in einigen Bereichen seiner Zeit voraus. Es ist aber eine Nische bzw. exotisch, auch wenn es noch so gut sein mag.
 
Zuletzt bearbeitet:
Ja, das ist mir klar geworden. Eine SID, die zudem noch „Windows-kompatibel” ist, hat hier klare Vorteile.

Solaris bzw Illumos/OmniOS nutzen keine "kompatible" sid sondern direkt z.B. die originäre eindeutige Active Directory SID mit der Domäne als Teil.

Sicher, dass das bei macOS so ist? Ich habe mich wie gesagt damit noch nicht beschäftigt. Die macOS GUI scheint eingeschränkt zu sein. Für mehr, muss man ins Terminal oder bestimmtes Tools nutzen (ich glaube von Marcel Bresink gibt es dazu etwas).


Der Mac greift auf das SMB Share zu und man hat die Rechte die auf dem Server gesetzt sind. OSX hat halt keine Möglichkeit die Rechte auf dem Server remote anzuzeigen, zu ändern oder User anzulegen. Das geht nur auf dem Server oder einem Windows Client.

Ich finde Solaris ja grundsätzlich toll. Solaris war in einigen Bereichen seiner Zeit voraus. Es ist aber eine Nische bzw. exotisch, auch wenn es noch so gut sein mag.

So isses leider. Apple hatte ja mal ZFS kurz in den Server integriert und überlegt, Sun zu kaufen. Stattdessen haben sie "Computer" aus dem Firmennamen entfernt und i Gedöns gemacht. Die Verbreitung von Solaris sähe heute ansonst anders aus...
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh