[Sammelthread] ZFS NAS Chezmoi

Ich werde mir die Software jedenfalls nicht auf den PVE-Host klatschen
Ich werd fürs erste mal TN weiterlaufen lassen.

Allerdings hab ich noch ne 2. Kiste mit MC12+5650+64ecc mit Proxmox rumstehen, da hindert mich eigentlich nur die Zeit dran...
Beitrag automatisch zusammengeführt:

Insofern find ich das ok, wenn sie den Teil (vorerst) draußen lassen.
ARC Settings sind aber schon wichtig... kannst ja wie bein Windows machen... "wird erst nach Neustark wirksam blabla".
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Kannste auch per CLI machen, sehe das nicht als Problem.
Bei TrueNAS kannste es auch nicht in der GUI einstellen, aber ein ein kleines Projekt muss das können.

Was für ne Meinung 🙄:fresse2:
 
Ne, verstehst du falsch, ich mein ja nicht, dass das deshalb schlecht ist.
Wird schon kommen, denk ich mal.

Wäre halt toll, wenn es das könnte.
 
@pwnbert
Sorry hatte das falsch verstanden

@gea Ich habe jetzt mal ein "zfs get acltype,aclmode pool/dataset" gemacht und habe folgende Ausgabe:
Code:
NAME         PROPERTY  VALUE        SOURCE
pool/dataset  acltype   nfsv4        local
pool/dataset  aclmode   restricted   local

Hatte ich das richtig verstanden, das ich das in der smb.conf änder muss oder brauche ich da einen Befehl für zfs?


Edit:
getfacl gibt mir folgendes aus:

Code:
# owner: user1
# group: user1
user::rwx
group::rwx
other::---

Das passt damit also soweit.

Edit2:
Habe jetzt mal die entsprechenden Werte in zfs gesetzt:
Code:
zfs set acltype=posixacl pool/dataset
zfs set aclinherit=passthrough-x pool/dataset
zfs set aclmode=passthrough pool/dataset
So jetzt kann ich zumindest die Ordner im Share sehen, aber noch nicht drauf zugreifen.

Edit3:
Die Samba Logs geben mir jetzt das hier aus, da muss ich mal weiter suchen:
Bildschirmfoto_20260318_184135.png
 
Zuletzt bearbeitet:
Das ZFS Dateisystem sollte man bei Linux smbshares auf acltype=posix und aclinherit + aclmode auf passthrough und xattr=sa setzen. Dann per chmod oder setfacl den usern Rechte auf die Dateien/Ordnern verschaffen und diese user oder groups in der smb.conf Zugriff erlauben. Dazu dann noch den usern ein SMB Passwort zusätzlich zum Unix Passwort vergeben. Dann sollte nach SAMBA Neustart der Zugriff per smb funktionieren.

ps
Ach wie herrlich einfach ist da doch Windows oder Solaris/Illumos Unix. Da klickt man im Windows Explorer auf eine Datei oder Ordner und kann mit oder ohne Vererbung mit Datei -> Eigenschaft -> Sicherheit die viel umfassenderen ntfs ACL für vorhandene lokale oder AD Nutzer oder Gruppen (mit Gruppen in Gruppen) setzen, ganz ohne das SAMBA Gewürge das letzendlich nichtmal die gleichen Features abbilden kann .....
 
Zuletzt bearbeitet:
bei smbshares auf acltype=posix und aclinherit + aclmode auf passthrough setzen
hab ich gemacht, siehe post.

Dann per chmod oder setfacl den usern Rechte auf die Dateien/Ordnern verschaffen und diese user oder groups in der smb.conf Zugriff erlauben.
hab ich auch gemacht.
Sogar ein testdataset mit dem entsprechenden User und zur Sicherheit noch mit chmod 777

Dazu dann noch den usern ein SMB Passwort zusätzlich zum Unix Passwort vergeben. Dann sollte nach SAMBA Neustart der Zugriff per smb funktioneren.
habe ich auch noch gemacht. Bzw. macht zfsnas automatisch

Ach wie herrlich einfach ist da Windows oder Solaris/Illumos Unix.
ja ja, Windows will ich nicht und Solaris kann wieder kein Docker und ist bei anderen Problemen absolute Nische. Da bekomme ich dann keine infos/hilfe.
 
ja ja, Windows will ich nicht und Solaris kann wieder kein Docker und ist bei anderen Problemen absolute Nische. Da bekomme ich dann keine infos/hilfe.

Nicht nur ZFS, auch Docker Container hat seinen Ursprung in Solaris (LX zones) und wird in Illumos (OmniOS, SmartOS) aktiv weiterentwickelt, neben Bhyve für Vollvirtualisierung. Auch ist Solaris/Illumos ZFS nach wie vor das stabilste ZFS. Das mit der Nische ist richtig, das ist z.B. OSX aber auch und die Nischen sind in ihrer Nische oft die besseren Lösungen. Ich habe bisher ausschließlich OmniOS als Storage eingesetzt weil es extrem viel einfacher ist als Linux oder SAMBA. Die neueren OpenZFS Features die in Illumos noch nicht umgesetzt sind sowie Proxmox und Windows mit ZFS bringen mich dazu, diese in die engere Wahl zu nehmen. Ich habe dafür auch meine web-gui OS unabhängig gemacht.

Windows mit released OpenZFS (der Begriff stable fällt mir bei OpenZFS immer etwas schwerer) ist etwas auf das ich richtig warte weil es manches besser und einfacher kann als Linux oder Unix.
 
Zuletzt bearbeitet:
kennt wieder keiner 😅

da höre ich nur Horrorstorys von

Ne, es reicht mir auf der Arbeit damit hantieren zu müssen, ich bin froh es zu Hause los zu sein.

Mit Linux kenne ich mich halt inzwichen ausreichend aus und den Rest kann ich gut im Netz suchen oder erfragen.
Sei mir nicht böse, das ich weder Solaris (und Nachfolger) noch Windows nutzen möchte.


Nebenbei, das erste Erfolgserlebnis!
Das Testshare funktioniert mit allen Lese-/Schreibrechten (y)
Jetzt muss ich nur noch vergleichen, was bei dem anderen Share anders ist und nicht funktioniert.
 
Ich will niemand bekehren und schaue selber auch über den Zaun.
Von Windows bin ich vor 15 Jahren weg wegen ZFS und überlege es mir erneut, auch wegen ZFS
 
So ich glaube ich habe den Fehler, also nicht den Fehler aber ich kann das Problem herleiten.
Also mit dem 1. Benutzer kann ich das Testshare nicht mounten, mit dem extra angelegten Testuser kann ich es mounten und auch beschreiben.
Ergo gibt es irgendein Problem mit dem 1. Benutzer.


Edit:
Ich habe den Fehler! :banana:

Durch meine Aktion mit Benutzer löschen und neu Anlegen mit einer anderen UID, hat Samba die falsche UID mit dem Sambauser verknüpft, das ist noch die alte.
Hier müsste eigentlich 3000 stehen:
Bildschirmfoto_20260318_200855.png

Jetzt muss ich nur noch herausbekommen, wie ich die User SID ändere oder den Benutzer neu verknüpfe.


Edit 2:
Habs hinbekommen, jetzt geht alles :banana:

Mit folgendem Befehl einfach die komplette User SID austauschen:

Code:
#samba stoppen
systemctl stop smbd

#User SID austauschen
pdbedit -u Username -U <SID>

#samba wieder starten
systemctl start smbd


Und jetzt gerne wieder zurück zum Thema des Sammlers, sorry für meinen Ausflug 😅
 
Zuletzt bearbeitet:
Das Problem mit Windows (auch auf dem Server) ist halt, das man da ständig hinterher sein muss um es daran zu hindern nach Hause zu telefonieren - das machts zum absoluten No Go. Ein NAS OS dem man nicht vertrauen kann ist einfach komplett raus, egal wie toll sein ZFS sein mag.
Was mich an chez moi stört ist der "trust me bro" Installationsvorgang.... mag ich gar nicht. Anschauen werd ichs mir trotzdem mal...
 
Es gibt vieles was man an Windows als Storageserver nicht mögen kann. Wenn man aber vernünftige ACLs und Auditing mit Active Directory und überragende Performance mit SMB Direkt z.B. für 4/8k Videoediting braucht, so betrachte ich es schlicht als alternativlos.

Trauen muss man jedem Hersteller oder Programm das man installiert und das Adminrechte braucht. Mit Bugs rechnen muss man bei jedem. Mit Spionage ist bei jedem nicht EU Programm per se zu rechnen, egal ob PRC , RU oder US. Wer meine napp-it web-gui installiert muss mir auch vertrauen, das Produkt ist aber schon 16 Jahre verfügbar.
 
v6.2.0 out now.
ZVOLS & iSCSI
iSCSI hab ich seit PVE-Zeiten gar nie mehr gebraucht. Aber der Entwickler ist konsequent, zu einem NAS gehört das. Mache heut sicher ein paar Test von/mit PVE. Bin gespannt, ob es Unterschiede zu NFS gibt.
1773896240578.png

1773896302499.png

1773896529406.png
 
Zuletzt bearbeitet:
Was mich an chez moi stört ist der "trust me bro" Installationsvorgang.... mag ich gar nicht.
Du meinst TrueNAS, oder?
Bei zfsnas chezmoi kannste dir das install Script ja anschauen. Soweit ich das gesehen habe nutzt er nur ganz normales apt mit Paketen aus den originalen Debian Quellen, erstellt sich seine Verzeichnisse und richtet einen Systems Service ein. Konnte nichts verwerfliches finden.

Mit Spionage ist bei jedem nicht EU Programm per se zu rechnen
Hab's mal korrigiert :fresse:
 
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