Benutzerrechte: everyone doppelt - und überhaupt....

[hok]

Hallo!

Ich hoffe hier Hilfe für (das leidige) Thema Benutzerrechte zu finden. Ich habe unzählige Forumsbeiträge und andere Quellen gelesen - ich muß einfach passen, als Nicht-ITler ist mir das zu komplex und ich finde nur sehr widersprüchliches.
Was ich will:
Einen Fileserver/NAS in meinem privaten Netzwerk ohne Anbindung an das Internet, ich bin der alleinige Nutzer. Benutzerrechte, die mir immer gewährleisten, z.B. ein Backup unkompliziert zurückzuspielen und jederzeit immer Zugriff auf die Dateien zu haben, ohne mich plötzlich Rechtekonflikten gegenüberzusehen. Zugriff auf die Freigaben erfolgt via SMB durch einen Windowsrechner und einem MacOS-Rechner.
Andererseits benötige ich Replication für die Backups (inhouse) und da wird es schon wieder komplexer: das erfordert ssh-Schlüssel etc. (richtig?), die wiederum in einem Userverzeichnis mit speziellen Rechten liegen müssen.
Welche Benutzerrechtestrategie ist nun für für meinen Anwendungsfall die beste?

Bisher habe ich folgende Konfigurationen ausprobiert:
TrueNAS Core 13.0 U5.2, ein Vdev Testpool aus 2 x 3TB HDDs (Mirror) mit zwei Datasets Daten_1 und Daten_2.
Daten_1 habe ich strikt nach der TN-Dokumentation konfiguriert:
Storage/Pools/Daten_1/Edit Permissions: ACL Preset: OPEN
SMB-Freigabe mit Standardeinstellungen
Meine Freigabe funktioniert, jedoch scheinen mir die Berechtigungen unverständlich:
die Ausgabe in der Shell verwirrt mich durch das doppelte Auftreten von everyone@:

root@server23[/mnt/testpool/Daten_1]# getfacl testdatei_MB.txt

file: testdatei_MB.txt
owner: hok
group: wheel
owner@:rwxpDdaARWcCos:------I:allow
group@:rwxpDdaARWcCos:------I:allow
everyone@:rwxpDdaARWc--s:------I:allow
everyone@:--------------:------I:allow

Was habe ich da falsch gemacht?

Ein zweiter Versuch mit dem zweiten Dataset Daten_2:
Storage/Pools/Daten_1/Edit Permissions: ACL Preset: Restricted, Benutzer und Gruppe geändert.
SMB-Freigabe mit Standardeinstellungen

Jetzt sieht die Ausgabe getfacl anders aus:

root@server23[/mnt/testpool/Daten_2]# getfacl testdatei_pc.txt
file: testdatei_pc.txt
owner: hok
group: hok
owner@:rwxpDdaARWcCos:------I:allow
group@:rwxpDdaARWc--s:------I:allow
everyone@:--------------:------I:allow

Aber wie ist es nun richtig? Welche Ebenen sollten welche Zugriffsrechte bekommen? Wer sollte Besitzer sein und welche Gruppe?

hok

 

[micneu]

ich mache es so das ich immer 2 gruppen anlege:
- daten_rw = alle die in der gruppe rw sind dürfen lesen/schreiben/ändern
- daten_ro = alle die in der gruppe sind dürfen nur lesen

ich vergebe nie benutzerechte direkt auf ein share sondern immer über gruppen

PS: meine empfehlung wenn du ein TrueNAS einsetzen willst solltest du dich schon ein wenig mit den berechtigungen auseinander setzen und auch ssh kann nichts schaden. das wirst du bei den meisten NAS systemen benötigen (Selbst für die DAU Tauglichen Synology oder QNAP)
und die sind kinderleicht zu bedienen :)

 

[hok]

Erst mal vielen Dank für das schnelle Hilfsangebot!
Genau das ist mein Problem: Ich habe keine User, die etwa nur lesen dürfen, ich verwende den Server ausschließlich allein. Eine Konfiguration der Benutzerrechte, die mir maximale Konfliktlosigkeit garantiert aber auch ssh und seine Konsequenzen in Bezug auf die Rechte berücksichtigt.
Bei mir läuft seit fast 12 Jahren ein Freenas, ich habe eine Reihe von wechselnden GUIs und unterschiedlichen Umsetzungen der Benutzerrechtefrage "durchgemacht" - bis heute habe ich die sich endlos widersprüchlichen Aussagen nicht zu einer Erkenntnis zusammenbringen können.
Und für ein IT-Studium reicht meine Zeit nicht - ich bin Fotograf ;) Viele Behaupten, das mit den Rechten ist eigentlich einfach - die Forenbeiträge sagen etwas anderes.

Mein naiver Traum war immer, es gibt eine Anleitung, die für meinen (simplen) Anwendungsfall ein nachvollziehbares Preset "Mach es so und sei Glücklich" gibt. Technik soll doch nen Nutzen haben...?!

Ich scheitere ja bei deinen Screeenshots schon an dem Umstand, wie da die langen SIDs reinkommen, warum Domain und Name ausgefüllt sind und woraus sich logisch die Felder Domain und Name ergeben... ich kann das nicht nachvollziehen. Da ist doch viel mehr ausgefüllt als die Doku oder dein Text dazu Aufschluß gibt und mir so die Abhängigkeiten/Notwendigkeiten nicht klar sind.
Erst kürzlich ist mir mit Schrecken aufgefallen, daß in meinem Backup (Replication) ein Verzeichnis fehlt. Am Ende war es nur eine warum auch immer falsch gesetzte ACL, die mir (nur) die Anzeige verhinderte. Solche "Schrecken" wollte ich mit dem Neuaufsetzen verhindern, sehe aber, daß in der V13.0 U5.2 schon wieder alles anders ist... Es ist zum verzweifeln!

Sorry für den langen Ausbruch ;)

hok

 

[Patrick M. Hausen]

Ich mache bei SMB die ACLs aus, den Gastzugriff an, und bin glücklich. Das klappt allerdings nicht mehr mit Windows-Clients, weil Microsoft das abgestellt hat. Wir sind hier ein 100% Mac Haushalt.

 

[hok]

Danke für dein Aufgreifen des "und sei Glücklich" ;)
Mein Mac ist gerade in der Reparatur... Aber die Workstation ist Windows und der wichtigste Rechner.
Was würdest du denn empfehlen, wie ich die Freigabe und ACL Dingens gestalte?
Ich bin bei dem Neuaufsetzen auch noch nicht zu der SSH-Geschichte vorgedrungen, die ich wegen der Replikationen brauche, die in TN13.0 schon wieder anders ist und ich meine ganzen Aufzeichnungen von "damals" weghauen kann. Brauche ich als alleiniger Nutzer ein Userverzeichnis mit entsprechenden Rechten für die Schlüssel, oder werden die jetzt intern gespeichert?
Welche ACLs brauche ich und muß sie wie konfigurieren?
Selbst meine Storage-Struktur ist einfach: ein Pool (künftig 4 x 18TB im RaidZ2) und ca. 6 Datasets. Keine VMs, Jails, Plugins usw. Ein blanker Fileserver, den ich ausschließlich wegen dem ZFS betreibe (+ ein fast identischen Backupserver).
Die ACL-Vorgabe "open" habe ich verwendet, so wie sie in der Doku steht. Der doppelte everyone@ (Google findet dazu nur 16 Ergebnisse, wovon nur 2 zutreffend, aber Apple betreffen) macht mich ratlos - diese Konfig kann nicht stimmen.

hok

 

[Patrick M. Hausen]

Leg dir einen Benutzer "hok" an mit einem Passwort, mach den zum Eigentümer und "Full Access" aller Shares, dann ist das Thema doch auch durch, wenn du der einzige Nutzer bist. Die ganzen Presets mit @Everyone etc. sind schnurz, die jucken dich doch nicht.

Die sind dafür da, dass in einer Umgebung mit tatsächlich mehreren Nutzern jeder sehen kann, wass für Shares es gibt. Das heißt ja noch nicht, dass man dann auch Zugriff hat. Die Vorgaben sind ganz sinnvoll ...

Das ist für die SMB Shares. Für die Replikation machst du SSH und SSH Root-Login an und hinterlegst die Schlüssel über das UI. Beim Benutzer "root". Der hat kein SMB-Homeverzeichnis, braucht er auch nicht.

Umgekehrt braucht dein Windows-Nutzer nirgends einen Schlüssel, der hat einen Benutzernamen und ein Passwort.