SMB vs NFS4 und Nutzerrechte

Probleme mit Samba, NFS, FTP und Co.
Benutzeravatar
weshalb
Beiträge: 1265
Registriert: 16.05.2012 14:19:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von weshalb » 07.12.2019 10:05:28

Simaryp hat geschrieben: ↑ zum Beitrag ↑
07.12.2019 09:09:26
Ok, ich würde mal sagen, die Benutzer, Gruppen und Rechte sind einigermaßen klar. Ein paar konkrete Fragen habe ich noch:
1a. Wenn ich die Nutzer für den externen Daten zugriff anlege, dann brauchen die wirklich kein home oder?
1b. Für den Dockernutzer wäre das mit dem /home die sinnvollste Lösung oder?
2a. Welchen Systemgruppen muss ich die mindesten zuordnen, abgesehen von den Ordnergruppen?
2b. Gleiche Frage für den Dockernutzer.
3. Wie kann ich mit chown und chmod einen initial sinnvollen Zustand für alle Ordner samt Unterordnern und Dateien erreichen?

Wenn ich am Ende ein schönes Skript habe, wie ich meinen Server angelegt habe, dann teile ich das natürlich gerne.

Ich bin auch schon fast entschlossen, dass es wieder Samba wird. Das mit Kerberos scheint mir das ganze doch recht zu verkomplizieren. Wegen der Samba-config, belese ich mich noch einmal und stelle dann noch mal ein paar qualifizierte Fragen.

Systemgruppen, Dockernutzer mit chown und chmod einen initial sinnvollen Zustand erreichen?

Mhh, ich würde dir vorschlagen, du nimmst erstmal ein Samba Tutorial und fängst an, Ordner so freizugeben, wir du es benötigst. Dann werden sich deine Fragen wahrscheinlich schon in Luft auflösen. Vielleicht hilft dir auch schon der zweite Link, den ich dir geschickt hatte?

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 07.12.2019 10:20:07

Ich meine damit folgendes: Wenn ich auf meinen Clients einen User anlege, mache ich das zur Zeit mit

Code: Alles auswählen

1. `$ useradd -m -G sys,games,power,wheel,audio,video -s /bin/bash "username"` ideally same name as NAS user
2. `$ passwd "username"`
Wenn ich jetzt aber einen Nutzer auf dem Server anlege, nur damit ich meine Shares mounten kann, dann brauche ich ja vermutlich gar nicht alle diese Gruppen, vielleicht sogar gar keine? Dockernutzer wäre halt ein Nutzer, den ich für meine Dockercontainer anlege.

Initial sinnvoller Zustand meint, dass ich das ZFS-Volume vermutlich als Root anlege und dann mit Daten von meinem USB backup befüttere oder aus dem Netzwerk durch ein Mount meiner NAS. Danach ist vlt. Root der Besitzer oder die UIDs der NAS stehen drin, ich weiß es nicht. Um Chaos zu vermeiden, möchte ich dann initial sicherstellen, dass die Rechte alle und Besitzverhältnisse alle richtig gesetzt sind. Also alle Dateien und Ordner eines Pfades gehören einem bestimmten Benutzer. Um evtl. ACL Reste oder Konfigurationen von der Synology NAS nicht zu übernehmen, sollen die Dateien und Ordner sinnvolle default Rechte bekommen.

Benutzeravatar
weshalb
Beiträge: 1265
Registriert: 16.05.2012 14:19:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von weshalb » 07.12.2019 11:02:50

Ich kann dir ehrlich gesagt nicht folgen. Die Abfolge ist doch diese:

Anlegen der User und Gruppen auf dem Debianserver
Zuweise der Rechte auf die einzelnen freizugebenen Ordner (Stichwort chown und chmod) auf dem Debianserver
Anlegen der Passwörter in Samba (Stichwort smbpasswd) auf dem Debianserver
Konfiguration der Freigaben innherhalb von Samba (Stichwort smb.conf) auf dem Debianserver
Mounten der Freigaben auf dem Client mittels dem Usernamen und zugehörigem Passwort aus smbpasswd

Bitte lese dir das durch, was ich dir geschickt habe. Ich bin dann erstmal raus.

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 07.12.2019 11:10:46

Was da fehlt ist, dass ich ja nicht ohne Daten Anfange, sondern die Daten dann von meinem Synology NAS auf den Debian Server migrieren möchte. Wenn ich die Hauptordner mit den gewünschten Rechten anlege und dann die ganzen Daten von meinem USB-Backup oder über das Netzwerk von der Synology NAS rüber kopiere, dann erben diese Dateien ja nicht automatisch die Besitzer und Rechte des übergeordneten Ordners. Um ein Rechte und Besitzerchaos zu vermeiden, müsste ich doch dann sicher stellen, dass all die migrierten Daten und Unterverzeichnisse die richtigen Setzwerte bekommen.

Benutzeravatar
weshalb
Beiträge: 1265
Registriert: 16.05.2012 14:19:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von weshalb » 07.12.2019 11:53:06

Dann kopiere sie halt rüber und passe, falls die Rechte nicht stimmen, diese mit chmod und chown rekursiv an.....

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 07.12.2019 17:15:12

Ich war mir nicht sicher, ob man da zwischen Ordnern und Dateien differenzieren muss.

Ich habe übrigens mal per SSH in meiner Synology NAS nachgeschaut. Da sind alle Ordner und Dateien 777 und haben ein + für ACL. Habe mal versucht mir das mit getfacl anzuschauen, aber das ging nicht. Vlt. verwaltet die NAS das anders. Ich habe mir auch mal die smb.conf, die smbinfo.conf und die smb.share.conf der NAS kopiert. Das kann ich vielleicht als Referenz nehmen, wenn ich mich durch das manual für die smb.conf durcharbeite.

Tut mir Leid, wenn manche Fragen zu noob sind, ich muss halt noch einiges lernen.

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von jph » 08.12.2019 14:54:42

TomL hat geschrieben: ↑ zum Beitrag ↑
06.12.2019 11:40:43
Hier bei mir zuhause haben sich die ALCs vor einem anderen Hintergrund als Katastrophe erwiesen. Ich werde die nie wieder einsetzen.
Magst du das etwas erläutern?

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 27.01.2020 06:49:04

@TomL

Mich würde auch die Katastrophe interessieren.

TomL

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von TomL » 27.01.2020 10:43:21

Möglicherweise war das auch ein Bedienungsfehler, aber bei mir war das Ergebnis mit ACLs ein Desaster. Ich würde deswegen einem Anfänger ACL-Rechte erst mal nicht empfehlen.

Das Problem damit ist, dass man damit quasi 2 konkurrierende Rechte-Systeme hat, denn das originäre Linux-Rechte-System lebt ja weiter. Und leider zeigen die Filemanager zum einen ACL-Rechte nicht an, zum zweiten weiß man gar nicht abschließend, ob ein Filemanager oder solche Tools wie DoubleCommander/Krusader oder auch Freefilesync mit oder ohne kopiert. Ein großes Problem war, wenn ich Dateien regulär zwischen Samba-Shares umkopiert habe, z.B. für temporäre Sicherung oder schlichtweg eine Übertragung von einem (für User) privilegierten (RW-) Bereich in einen unprivilegierten (R--). Auf einmal hatten User im neuen Directory Schreib-Rechte (und auch Lösch-Rechte) für Dateien, die sie eigentlich nur lesend öffnen können sollten.

Beim normalen Copy/Move werden die Force-Anweisungen in der smb.conf berücksichtigt und gegebenenfalls neue UID/GID und RWX-Attribute gesetzt, leider bleiben aber die ACLs bleiben davon unberührt. Das bedeutet, man erwartet gesetzte Rechte, die werden aber durch andere Rechte neutralisiert. Ich würde ACLS heute nur noch in Share-Dirs mit quasi statisch vorhandenen Dateien oder neu erstellten und danach am Ort verbleibenden Dateien verwenden, wenn mehrere User darauf zugreifen müssen. Aber das konnte ich ja auch mit force-Anweisungen in der smb.conf erreichen. Sobald aber eine gewisse Bewegungsdynamik zwischen Dateien und Speicherorten besteht, mit begleitenden jeweils anderen Rechten, hat man das kaum noch unter Kontrolle.

ACLs sind imho die perfekte Lösung für in statischen den Usern zugewiesenen Bereichen, wo Dateien einmalig angelegt werden und immer dort verbleiben.. so typische Büro-Abteilungs oder Team-Ordner mit hierarchischen Berechtigungen. Sobald aber Dateien verschoben werden, besteht imho eine hohe Gefahr, dass danach (meistens unentdeckt) die falschen ACL-Rechte gesetzt sind. Bei mir war der Effekt nach längerer Zeit ein unüberschaubares Rechte-Chaos. Ich persönlich komme deutlich besser allein mit Linux-Rechten klar.

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 27.01.2020 19:21:59

Sehr aufschlussreich.
An sich wären ACLs ja eine wirkliche sinnvolle Erweiterung der POSIX Rechte oder sogar besser Ersatz. Doof ist natürlich, wenn es dann zig verschiedene "Standards" gibt, die alle wiederum nicht übersetzbar sind und schnell ein riesiges Chaos entsteht.
Gefühlt brauchte ich persönlich gar keine Rechte auf Dateilevel. Zumindest was Daten angeht, würde es mir eigentlich reichen, für einige Hauptverzeichnisse für die Einzelnen Nutzer eine Zugriffsmatrix auszufüllen, die dann automatisch für alle Dateien und Ordner die darunter liegen gilt. Aber es wird bestimmt gute Gründe geben, warum das niemand so macht. Wahrscheinlich wird sich auch nie viel daran ändern aus Kompatibilitätsgründen.

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 30.01.2020 08:21:58

Ich habe mal versucht, mich durch die automatische smb.conf meiner Synology NAS, die man pages und das ganze Internet durchzuwühlen.
Samba hat so viele Optionen, da verliert man schnell den Überblick. Eine grundlegende Frage, die sich mir gestellt hat, wenn ich etwas nicht angebe, wird dann der default Wert genommen, oder das feature einfach nicht genutzt? Ich würde ja ersteres denken, habe aber so viele configs gesehen, wo explizit default werte gesetzt werden.
Bei der Synology smb.conf gab es viele Einträge, die in den man pages gar nicht zu finden waren. Ich gehe mal davon aus, dass es dabei um synology spezifischen Kram gibt.

Im ersten Anlauf bin ich jetzt bei folgendem Entwurf gelandet für global und ein Share. Wenn ich es richtig verstanden habe, brauche ich die auskommentierten Zeilen nicht, wenn ich initial die Rechte auf dem Server richtig setze und die inherit Option nutze. Vielleicht umgehe ich damit dann auch dieses Problem: https://jrs-s.net/2013/04/10/force-dire ... samba-3-x/

[global]
workgroup = oz
server role = standalone server
passdb backend=smbpasswd
encrypt passwords = yes
smb encrypt = desired
server min protocol = SMB2_10
server max protocol = SMB3
unix extensions = yes
inherit permissions = yes
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
show add printer wizard = no


[media]
comment = Media share
path = /pool/media
browseable = no
valid users = @media
# force group = @media
public = no
writable = yes
write list = tick
read list = @media
# create mask = 0640
# directory mask = 2750
# force create mode = 0664
# force directory mode = 2775
vfs object = recycle

TomL

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von TomL » 30.01.2020 11:22:43

Simaryp hat geschrieben: ↑ zum Beitrag ↑
30.01.2020 08:21:58
Eine grundlegende Frage, die sich mir gestellt hat, wenn ich etwas nicht angebe, wird dann der default Wert genommen, oder das feature einfach nicht genutzt?
Das kannst Du für die meisten Optionen hier nachlesen: https://www.samba.org/samba/docs/curren ... onf.5.html. In der Options-Beschreibung wird angezeigt, wie der Default-Wert ist. Du kannst Dir auch den Zustand/Wert aller aktiven Parameter ansehen:

Code: Alles auswählen

testparm -v -s | less

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 30.01.2020 20:42:13

Also ist die Angabe von Settings die default sind redundant und man könnte es lassen. Abgesehen von der Sorge, die defaults könnten sich ändern. Aber dann müsste man ja im Prinzip alle parameter ausdefinieren und hat nachher eine 1000 Zeilen smb.conf.

Hast du vlt. ein Feedback zu meinem Entwurf und meinem Verständnis von inherit?

TomL

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von TomL » 30.01.2020 23:25:54

Simaryp hat geschrieben: ↑ zum Beitrag ↑
30.01.2020 20:42:13
Hast du vlt. ein Feedback zu meinem Entwurf und meinem Verständnis von inherit?
Das ist immer schwierig, weil man die Anforderungen nicht kennt. Deswegen nur am Rande....

server min protocol = SMB2_10 würde ich durch
server min protocol = SMB2 ersetzen, das umfasst die ganze 2er Protokoll-Familie. Wobei Du kontrollieren solltest, ob Android-Geräte das können. Bis Android 10 verwenden die per default das vorherige Protokoll NT1 unverschlüsselt. Mit der Beschränkung auf SMB2 wird das auch genutzt, verschlüsselt. Aber wie gesagt, vorher kontrollieren, ob die Android-Version das kann.

server max protocol = SMB3 ist eine schlechte Wahl. Welchen sinnvollen Grund sollte es haben, nach oben zu limitieren und damit ggf. ein besseres Protokoll zu verhindern, obwohl vielleicht beide Geräte das unterstützen?

inherit permissions = yes habe ich nicht verwendet, weil meine User sowieso mit Ihrer UID und mit eigenen Rechten mounten. Da muss nix vererbt werden, dass passt immer. Und für alle gemeinsamen Verzeichnisse habe ich im Share die Rechte explizit vorgegeben, z.B.
force group = sambauser
create mask = 0770
force create mode = 0660
directory mask = 0770
force directory mode = 0770


Dabei muss man aber darauf achten, dass das in Konflikt mit inherit permissons steht... also Man-Page lesen und ggf. Auswirkung vergleichen, bestätigen oder prüfen.

unix extensions = yes ist für mich schwierig zu packen... das unterstützt Sym- und Hardlinks... mir hat das irgendwie ein schlechtes Gefühl gemacht... ohne das jetzt handfest erklären zu können. Ich will keine systemübergreifenden Links, weil mir da möglicherweise die Kontrolle z.B. bei Backups entgleiten kann. Der Anwender speichert lokal, symlinkt auf dem Server, der Server backup'd, Datei ist nicht im BAK enthalten. Ich habe das aber nicht geprüft, ich habe aus faulheit nur dem suspekten Gefühl nachgegeben... also keine Links, bei mir no.

Ich habe zudem disable netbios = yes (Port 139) gesetzt. Falls das zu Problemen führt, ggf. zusätzlich smb ports = 445 ausdrücklich setzen. Dann ist noch map archive = no disabled. map archive verhindert falsche executable-flags (bei mir vor dem Hintergrund, dass auf Shares sowieso keine Executables erlaubt sind oder ausführbar sind). Das muss man aber selber hinsichtlich der Auswirkung prüfen, dass ist ggf. auch von den Mount-Options des Clients abhängig.

Viel mehr kann ich dazu auch nicht sagen....

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 30.01.2020 23:56:19

Ja, die Möglichkeiten und die Ausdifferenzierung für den individuellen Bedarf scheint bei Samba extrem zu sein.

Bei mir sollen wirklich nur Linux Clients die Shares mounten. Das sind zur Zeit drei Arch-Installationen und ein LibreElec. Ich will keine ACLs, kein Windows, keine Drucker und so weiter. Die Shares müssen in keinem Dateibrowser im Netzwerk zu finden sein etc.

Mein Andwendungsfall ist wirklich minima. Ich habe Shares in denen ich den Dateibesitz und die Rechte auf dem Server festgesetzt habe.
Auf den Clients will ich per systemd script per cifs oder bei libreelec über systemtools den Server und die Shares angeben und mounten. Dabei sollen Rechte und Besitz möglichst transparent sein und konsistent zu den Einstellungen auf dem Server sein.

Ob die Abgrenzung nach oben Sinn macht habe ich mich auch schon gefragt.

Bezüglich der Rechte Geschichte. Da bin ich wie gesagt sehr überfragt, was der beste Weg ist, um meinem Ziel gerecht zu werden. Im Prinzip will ich, dass neue Dateien und Ordner die gleichen Benutzer und Rechte bekommen, wie es bereits in dem share ist.

unix extensions waren in der Synology Config gesetzt. Ich habe in den man pages bloß gelesen, dass es für cifs Unterstützung was taugt. Aber bei genauerem Lesen kann man es wohl weglassen.

Was bringt mir das deaktivieren von netbios? Beziehungsweise wofür ist es gut. In den man pages steht, dass das für Win 2000 zB ok wäre, bei anderen Betriebssystemen (Windows?), aber Probleme macht. Wie gesagt ich habe keine mounts in Windows oder Android.

Brauche ich diese ganzen Sachen, die ich zu Printern angegben habe oder reicht es, einfach keinen Abschnitt zu Printern zu haben?

TomL

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von TomL » 31.01.2020 12:00:32

Simaryp hat geschrieben: ↑ zum Beitrag ↑
30.01.2020 23:56:19
Brauche ich diese ganzen Sachen, die ich zu Printern angegben habe oder reicht es, einfach keinen Abschnitt zu Printern zu haben?
Ich nutzte samba nicht für den Netzwerk- Drucker, sondern Cups... was seit Jessie geradezu perfekt funktioniert.
Simaryp hat geschrieben: ↑ zum Beitrag ↑
30.01.2020 23:56:19
Was bringt mir das deaktivieren von netbios? Beziehungsweise wofür ist es gut. In den man pages steht, dass das für Win 2000 zB ok wäre, bei anderen Betriebssystemen (Windows?), aber Probleme macht.
Netbios (Port 139) ist an sich ein kritisches Protokoll... und nur Windows-Versionen bis Win2000 erfordern das zwingend. Microsoft hat das Protokoll wegen der Mängel auf ein TPC/IP-Basiertes (Port 445) geändert, welches alle späteren Windowsersionen natürlich auch unterstützen. Der Vorteil ist, eine potentielle Gefahrenstelle zu eliminieren. Port 139 ist nicht notwendig, bei mir gibts kein so altes Gerät oder Betriebssystem, welches das noch erfordern würde.

Das Problem der Berechtigungen ist, dass man Dir eigentlich nicht wirklich raten kann, was richtig ist.... weil man nicht so recht Deine Anforderungen oder Deine Vorstellungen zum Server kennt. Ich kann nur grob umreissen, wie ich das hier gelöst habe und warum das so ist.... ob das für Dich geeignet ist, habe ich keine Ahnung.
  1. Prämisse: Es gibt userbezogene, rein private Verzeichnisse auf dem Server, mit exklusiven Rechten nur für den User
  2. Prämisse: Es gibt allgemeine Verzeichnisse, auf die alle User zugreifen dürfen, Multimedia, Dateien von gemeinsamen Interesse
  3. Prämisse: Es gibt geschützte Verzeichnisse, die nur für den Admin (für mich) relevant sind
  4. Prämisse: Keine Server-Platte kann von den Clients als "himself" gemountet werden
  5. Prämisse: Auf den Serverplatten können durch die Clients keine Devices oder ausführbare Programme betrieben werden
  6. Prämisse: Das Handling muss einfach sein, der Aufwand auf den Clients minimiert gering, möglichst zentral, am Server via Samba... auf den Clients nur ein paar Dateien kopieren und ggf. die Gruppe 'sambauser' mit den berechtigten Usern anlegen.
  7. Prämisse: Die Datenstrukturen müssen Backups perfekt unterstützen
Zu 1.
Auf der Server-Platte (bei mir SSD) gibts ein Verzeichnis /media/Home, welches weiter jeweils unter dem Namen der Linux-User für jeden User ein eigenes Verzeichnis hat, was auch seitens der Rechte diesem Linux-User gehört. Die User selber haben keinen Zugang zu /media/Home, das ist kein Samba-Share! Über die Home-Section in der smb.conf können die User aber auf ihr Server-/home Zugreifen. Für jeden User findet nun einfach ein bind in der server->fstab statt, wo z.B. das User-Verzeichnis SSD->/media/Home/thomas lokal auf dem Server nach SSD->/home/thomas/SHome gebinded wird. Der User selber kann dann an seinem Client-PC mit einem Mount "/bin/mount //server/homes/SHome /home/%I/SHome" sein persönliches Server-Daten-Verzeichnis in sein lokales Homedire mounten. Samba unterstützt das wirklich perfekt. Der Vorteil ist, die Shares laufen immer genau unter dem User, der den Share mountet und bekommt auch die Rechte des Users. Zugriffe durch andere User im LAN ist gar nicht möglich... ebensowenig unerlaubte Übergriffe durch laufende Programme auf anderen Systemen... nur dieser User mit seinen Rechten hat Zugriff.
Die SSD ist ausschließlich gedacht für die sehr dynamischen Bewegungsdaten, Office-Dokumente, Mail-Systeme, Cal/Card-Dav, etc... also die typischen Daten aus dem Userspace mit hohem Änderungsaufkommen. Das Backup-Volumen soll idealerweise < 5GB bleiben, damit es noch via FTP auf den Web-Space (natürlich verschlüsselt) gesichert werden kann. Hier handelt es sich ja ausschließlich um durch oder von den Users selber laufend generierten Daten.... mit dem Attribut, dass diese Daten ohne aktuelles Backup nicht oder nur mit unverhältnismäßigen Aufwand wiederhergestellt werden können.

Zu 2.
Hier ists einfach... keine individuellen Rechte, die Gruppe wird generell mir RW auf die ID "sambausers" gesetzt. Auch das macht samba klasse. Hier ists ein Datengrab für statische Daten, typisch Multimedia, alles was groß ist, viel Speicherbedarf erfordert, sich nie oder kaum verändert (z.B. Foto-Archive), alles, was nur Kategorie 2 bei den Backups ist... ist ja bei Verlust alles mehr oder weniger leicht wieder beschaffbar. Das ist also eine klassiche HD mit mehreren TB.

Zu 3.
Ist ebenfalls einfach ...der Umstand, dass der Share nur mich als User zulässt, verhindert den Zugriff anderer. Auch das ist erfolgreich mit Samba gelöst. Meistens Install-Pakete, oder Source-Codes aus Project-Web-Sites. Wegen des teilweise hohen Speicherbedarfs und der wirklich leichten Wiederbeschaffbarkeit alles nur Kategorie 3 bezogen auf die Backups. Liegt alles in einem eigenen Verzeichnis auf der HD.

Zu 4.
Es sind in der smb.conf zwar Shares für die Platten/SSDs eingerichtet, aber die können nur im Terminal mit root-Rechten und nur von mir gemountet werden. Zu Wartungszwecken braucht man das natürlich. Ebenfalls erfolgreich mit Samba gelöst.

Zu 5.
Ist in den Mounts (noexec, nodev) auf dem Client geregelt, die durchgeführt werden, wenn sich ein User anmeldet. Das kann man umgehen, aber nur wenn man weiss wie... für normale User quasi unlösbar.

Zu 6.
Ist bei mir mit einem eigenen tool realisiert....

Zu 7.
Also... für mich war das mit einer der wichtigste Überlegungen überhaupt, die Datenstruktur an der Notwendigkeit der Backups auszurichten... denn gerade dafür will ich Erfolgsgarantien bezogen auf die Wiederherstellbarkeit wichtiger Daten. Aber ich will keinen individuellen Aufwand dafür... das soll mannlos laufen. Also die Backups waren echt eine Basis aller Überlegungen... auch das habe ich mit einem eigenen tool gelöst. Bei mir sinds mittlerweile nur keine 3 dedizierten Raspi's mehr, sondern ein Intel NUC mit 3 VMs... aber prinzipiell wurde die Logik 1:1 beibehalten.

Aber wie gesagt... das alles kann jetzt hier nicht mehr als nur eine Anregung sein... ein paar Ideen... was davon brauchbar ist, entscheiden Deine Anforderungen.

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 31.01.2020 13:25:25

Vielen Dank für deine ausführlichen Erklärungen. Ich glaube, dass geht schon über meinen Usecase weit hinaus.
Basierend auf unserer Diskussion hier, habe ich folgenden Plan für Nutzer und Gruppen erstellt:

Code: Alles auswählen

##Users and Groups
A lot of groups and users is needed to get a KISS like right management for stored data. The idea is to create one group for each dataset and add all the users to it that should have access to the folder. For not too complicated use cases the access can be controlled with the posix rules and no ACLs are needed. In principle some users don't need a home on the server for current needs but since there is no harm and maybe usefull if needs change, they are created anyway.

###Creation of users
The following users need to be created:
* tick
* trick
* track
* htpc (for access with HTPC)
* docker (for running docker containers)

For each do the following:
adduser <username> --gecos ""
and follow the instructions.

###Creation of groups
For each dataset we need an extra group. Groups can be added with the groupadd command, gid can be specified with the -g <number> option. Since a group for each user is added automatically, the folders with usernames are created already.
Check first if GIDs are available and copy the following to console:
groupadd -g 1003 media
groupadd -g 1004 fotos
groupadd -g 1005 tmp

###Setting rights for files
The idea is that all datasets and the recursive files and folders belong to the group with the dataset name. The owner of the files is set initially to one user that has to be member of that group. By setting the rights to ether 770 or 740 one can define if the other group members can only read or in addition write to the files and folders.

####Adding users to groups
usermod -aG track media fotos tmp tick
usermod -aG track media fotos tmp trick
usermod -aG media htpc
usermod -aG media docker

####Setting owner and file mode
chown -R tick:tick /pool/tick
chown -R trick:trick /pool/trick
chown -R tick:track /pool/track
chown -R tick:media /pool/media
chown -R tick:fotos /pool/fotos
chown -R tick:tmp /pool/tmp

find /pool/tick/ -type d -exec chmod 770 {} +
find /pool/tick/ -type f -exec chmod 660 {} +
find /pool/trick/ -type d -exec chmod 770 {} +
find /pool/trick/ -type f -exec chmod 660 {} +
find /pool/track/ -type d -exec chmod 770 {} +
find /pool/track/ -type f -exec chmod 660 {} +
find /pool/media/ -type d -exec chmod 750 {} +
find /pool/media/ -type f -exec chmod 640 {} +
find /pool/fotos/ -type d -exec chmod 770 {} +
find /pool/fotos/ -type f -exec chmod 660 {} +
find /pool/tmp/ -type d -exec chmod 770 {} +
find /pool/tmp/ -type f -exec chmod 660 {} +
Sambanutzer sind im Prinzip nur tick, trick, track und HTPC. Alles auf Linux-Rechnern. Die Benutzerverzeichnisse sind im Prinzip sowas wie ein /home Archiv. Da kommen halt alle Daten rein. Die eigentlichen /home Verzeichnisse auf den Rechnern sind nur noch sowas wie ein /tmp, um halt Dateien zu erstellen und bearbeiten und alles was dann fertig ist, kommt rüber in die Verzeichnisse mit dem Namen. Daneben gibt es noch Verzeichnisse, in denen Tick und Trick gemeinsam arbeiten und erstellen dürfen. HTPC soll halt nur in dem Mediaverzeichnis lesen dürfen, aber auf keinen Fall irgendwas ändern. Ich sehe gerade noch, dass noch ein /recordings Verzeichnis fehlt, welches ich auf der ssd und nicht im ZFS-Pool anlegen will, aber das ändert glaube ich für die grundlegende smb.conf erst mal nichts.

Ich will eigentlich nur, dass die Rechte und der Besitz so fortgeführt wird, wie vorgegeben, also dass die Gruppe immer die Gruppe des Verzeichnisses ist und jeder nur das darf, was auf dem Server eingestellt wurde. Ich will also keine extra Samba-Rechte, sondern es soll alles so laufen, als wären die Nutzer lokal am Werk.

Antworten