[gelöst] Samba: User verstehen

Probleme mit Samba, NFS, FTP und Co.
MoonKid
Beiträge: 510
Registriert: 12.03.2012 22:36:43

[gelöst] Samba: User verstehen

Beitrag von MoonKid » 19.01.2017 23:43:21

Bin kurz davor einen eigenen Samba-Server aufzusetzen und lese dazu diverse Wikis/HowTos.

Was ich bisher fand, waren step-by-step-Anleitungen ohne Background-Infos. Daher verstehe ich das mit den Usern nicht.

Was ist ein Samba-User konkret?
Ist ein Samba-User auch ein Linux-User auf dem Server-Rechner?
Hatte aber auch gelesen, dass Samba Passwörter anders speichert, als Linux.
Muss ich einen Linux-User anlegen, um einen gleichlautenden Samba-User zu haben? Passwörter werden aber zwei angelegt?

Bin da etwas verwirrt.
Zuletzt geändert von MoonKid am 12.02.2017 11:28:47, insgesamt 1-mal geändert.

MSfree
Beiträge: 6051
Registriert: 25.09.2007 19:59:30

Re: Samba: User verstehen

Beitrag von MSfree » 20.01.2017 08:18:49

MoonKid hat geschrieben:Ist ein Samba-User auch ein Linux-User auf dem Server-Rechner?
Ja, ein Linuxuser ist Voraussetzung für einen Sambauser.
Muss ich einen Linux-User anlegen, um einen gleichlautenden Samba-User zu haben?
Jein.
Man kann Samba so automatisieren, daß bei Anmeldung eines unbekannten Benutzers ein Linuxuser erstellt wird, mit dem dann ein Sambauser erzeugt wird.
Passwörter werden aber zwei angelegt?
Jein.
Auf das Linuxpaßwort kann man verzichten, wenn der User nur auf die Sambashares zugreifen können soll.

Benutzeravatar
Huck Fin
Beiträge: 1074
Registriert: 10.03.2008 17:10:30

Re: Samba: User verstehen

Beitrag von Huck Fin » 20.01.2017 09:16:09

Ich denke, der Linuxuser ist notwendig, da man ja Rechte (r-w-x) für User und Gruppen verwalten muss.

TomL
Beiträge: 5211
Registriert: 24.07.2014 10:56:59

Re: Samba: User verstehen

Beitrag von TomL » 20.01.2017 11:28:44

MoonKid hat geschrieben:Bin kurz davor einen eigenen Samba-Server aufzusetzen und lese dazu diverse Wikis/HowTos.
Was ich bisher fand, waren step-by-step-Anleitungen ohne Background-Infos. Daher verstehe ich das mit den Usern nicht.
Ja, das ist einer der für mich am schwierigsten zu vermittelnden Punkte, wenn man das wie gewohnt mit Windows-Augen betrachtet. Unter einer Standard-Debian-Einrichtung zweier Maschinen, von denen der "Admin" einen als Server mit Samba nutzen möchte und den anderen als Arbeitsplatz-Enduser-PC, also als Client, braucht man quasi eine dreifache User-Einrichtung.

Anders als unter Windows werden unter Debian Benutzer-Berechtigungen nicht von ganz "oben" bis nach "unten" per default synchronisiert durchgereicht. Auch können Rechte auf Dateien nicht abschließend vom Client auf dem Server gesetzt werden. Das heisst, ich kann nicht so einfach ein Recht auf eine Datei setzen oder vergeben, welche auf dem Samba-Server gespeichert ist. Samba legt letztendlich die Datei auf dem Server an und setzt die Rechte dafür ..... innerhalb des vom Linux erlaubten Rahmens. Das bedeutet in der Folge, dass die Rechte, die ich von einer Samba-Datei auf dem Client angezeigt bekomme, nur Fake-Anzeigen sind, die überhaupt nicht mit den Rechten übereinstimmen müssen, die tatsächlich auf dem Server angelegt sind.

Ein Beispiel: Der Server-User "Fritz" hat die UID 1005, der Client-User "Otto" hat auf dem Client-PC auch die UID 1005. Nun würde der Client-User eine dem Server-User 1005 (also Fritz) gehörende Datei als dem Besitzer "Otto" gehörend angezeigt werden. Das ist natürlich Unsinn. Um dieses Dilemma zu lösen, kann man UID- und GID-Parameter beim Mounten setzen, die quasi in der Client-Anzeige einen Besitzaufkleber auf die wirklichen Rechten draufpappen.... also das ist wirklich nix anderes als ne Tapete, die die Wand verbirgt.... nur um eine Anzeige zu bereinigen. Ein technischen Effekt aufs Speichern hat es nicht. Aber das funktioniert trotzdem ausreichend gut.

Man kann Samba an folgende wesentliche Regeln festmachen:
1. Auf dem Client-PC muss ein User vorhanden sein

2. Auf dem Server muss ebenfalls ein User vorhanden sein. In unserer Vorstellung ist das der gleiche User wie auf dem Client, technisch betrachtet sind das aber 2 User

3. Auf dem Server verwaltet Samba ein eigenes Berechtigungssystem, welches sich aber nur innerhalb der von diesem Host vergebenen Linux-Rechte bewegen kann. Das heisst, samba kann auf diesem Host keine Linux-Mindestrechte unterschreiten und sich auch nicht über Linux-Maximalrechte hinwegsetzen.

4. Beim User dieser zwei Systeme kann es sich durchaus um die gleiche Person handeln, er kann aber trotzdem auf beiden Systemen einen unterschiedlichen Namen und Password haben. Eben deshalb, weil er sich sowieso auf jeder Maschine explizit identifizieren muss. Der Einfachheit halber verwendet man aber immer gleichen Anmeldenamen und gleiches Password. Schaut man jedoch auf die UID des Users beider Rechner, so kann man feststellen, dass die UIDs evtl. unterschiedlich sind.... eben deshalb, weils sie nicht per default synchronisiert werden.

5. Da Samba ein eigenes Berechtigungssystem berücksichtigt, muss ein vom Client-PC zugreifender User eben auf diesem Server auch als Samba-User eingerichtet werden. Aber es können nur Samba-User eingerichet werden, die gleichzeitig auch auf diesem Host reguläre Linux-User sind..

6. Theoretisch wäre es auch hier denkbar, dem Samba-User (zwar mit gleichem Namen, dennoch) ein vom Linux abweichendes Password zu vergeben. Aber auch das ist aus praktischer Sicht wenig sinnvoll.

7. Wenn ein Client-User sich mit einer Samba-Ressource verbinden möchte, so benötigt er zwei Anmeldungen: 1. die auf seinem Client-PC, 2. beim Verbinden zum Server den entsprechenden Samba-User und das Samba-PWD. Interessant ist, dass hierbei der Linux-User auf dem Server nicht verwendet wird - der ist nur dafür notwendig, damit man überhaupt den Samba-User auf dem Server anlegen kann.

Was kann ich nur mit diesen Anmeldedaten tun...?... als erstes natürlich die Grundfunktion: Anmelden als User auf dem Client und mit gleichem User-Namen + PWD die Samba-Freigaben vom Server verbinden. Aber richtig spannend wird es, wenn sich z.B. in einer Familie auf einem Client mehrere Personen zu unterschiedlichen Zeiten anmelden. Da wird es mit dem Mounten der Freigaben in der statischen fstab nämlich kompliziert, weil die fstab die Freigaben vor der Anmeldung mountet. Das heisst, man kann das an diesem Punkt gar nicht User-Anmeldungsbezogen handhaben.

Für dieses Problem gibt es verschiedene Ansätze. Einer davon wären die PAM-Mounts, die tatsächlich analog zu Windows userbezogen nach der Anmeldung stattfinden. Ich habe das ausführlich getestet und bin dann für unsere Anwendungen zu dem Schluss gekommen, dass traditonell über fstab bzw. mein Script "mountctl" und einer Unit "mountctl.service" für uns die bessere Variante ist.
Sowohl auf dem Server als auch auf allen Clients sind unsere User unter Linux und unter Samba eingerichtet. Ich -als admin- mounte auf allen Clients die 'öffentlichen' Freigaben unter meinen Server-Zugangsdaten, also die Freigaben, auf die alle zugreifen müssen und erlaube dann den anderen Familienmitgliedern den Zugriff auf 'meine' mounts . An dem Punkt könnte man anmerken "aber dann müssten doch die anderen Mitglieder gar nicht auf dem Server angemeldet sein". Ja, das ist richtig, aber neben den öffentlichen Mounts finden mit den persönlichen Anmeldedaten der anderen jeweils auch noch mounts in deren eigene lokale Client-Homedirs statt. Also z.B. deren auf dem Server gespeicherten Mail-Profile, oder eben deren eigene private auf dem Server gespeicherten Daten-Verzeichnisse, die auch ins lokale eigene Client-Home-Dir gemountet werden.

So.... als erster Rundumschlag wird das wohl reichen.... wenn noch was unklar ist, frag einfach noch mal....

Hth
vg, Thomas

Benutzeravatar
TRex
Moderator
Beiträge: 6611
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: Samba: User verstehen

Beitrag von TRex » 20.01.2017 13:14:11

TomL hat geschrieben:Ein Beispiel: Der Server-User "Fritz" hat die UID 1005, der Client-User "Otto" hat auf dem Client-PC auch die UID 1005. Nun würde der Client-User eine dem Server-User 1005 (also Fritz) gehörende Datei als dem Besitzer "Otto" gehörend angezeigt werden. Das ist natürlich Unsinn. Um dieses Dilemma zu lösen, kann man UID- und GID-Parameter beim Mounten setzen, die quasi in der Client-Anzeige einen Besitzaufkleber auf die wirklichen Rechten draufpappen.... also das ist wirklich nix anderes als ne Tapete, die die Wand verbirgt.... nur um eine Anzeige zu bereinigen. Ein technischen Effekt aufs Speichern hat es nicht. Aber das funktioniert trotzdem ausreichend gut.
Vorsicht TomL, nicht dass du das jetzt mit NFS verwechselt. Bei Samba meldest du dich mit einem Benutzernamen an, deine ID wird nicht übertragen.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!

TomL
Beiträge: 5211
Registriert: 24.07.2014 10:56:59

Re: Samba: User verstehen

Beitrag von TomL » 20.01.2017 13:38:21

TRex hat geschrieben: Bei Samba meldest du dich mit einem Benutzernamen an, deine ID wird nicht übertragen.
Ja, richtig, GENAU DAS sollte das Beispiel ja verdeutlichen. Man meldet sich zwar mit Namen an, aber diverse Client-Filemanager erzeugen möglicherweise ihre Anzeige über die Datei-Rechte-UID's der auf dem Server gespeicherten Dateien ... und das führt dann ggf. zu einer falschen Anzeige. Dieses Phänomen kann man einfach reproduzieren.Und genau diese fehlerhafte Anzeige beheben die UID- und GID-Parameter im Mountbefehl - die zwar keinen Einfluss auf die tatsächlichen Rechte haben, sondern nur auf die Anzeige, bzw. auf das, was der bekommt, der diese Rechte liest.
vg, Thomas

MoonKid
Beiträge: 510
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 20.01.2017 19:43:35

Geiles Zeug! Das musst du unbedingt in einer FAQ, einem HowTo oder Blog-Post verewigen.

Zu den UID hab ich noch mal ne Nachfrage. In deinem Beispiel...

Sieht der admin auf derm Samba-Server:

Code: Alles auswählen

-rw-r--r--  1 Fritz Fritz      476 Nov 15  2015 myfile
Und der Benutzer Otto auf einem Client, sieht an der Stelle aber

Code: Alles auswählen

-rw-r--r--  1 Otto Otto      476 Nov 15  2015 myfile
Weil beide auf ihrem jeweils eigenen System die UID 1005 haben. Soweit richtig verstanden?

Wie und wo kommen hier die mount-Parameter ins Spiel? Was würden die an der Ansicht verändern?

Und kann man beim Anlegen eines Linux-Nutzers die UID eigentlich beeinflussen, um solche Dinge zu umgehen? z.B. könnte man ID-Räume (wie bei IPs) vergeben. Auf dem Server alle Nutzer 1*** und auf dem Client alle 2*** usw.

TomL
Beiträge: 5211
Registriert: 24.07.2014 10:56:59

Re: Samba: User verstehen

Beitrag von TomL » 20.01.2017 20:25:52

MoonKid hat geschrieben:Weil beide auf ihrem jeweils eigenen System die UID 1005 haben. Soweit richtig verstanden?
Genau das ist so richtig. Und falls es auf dem Client zufällig keinen User gibt, der ebenfalls die UID 1005 hat, würde da einfach nur 1005 stehen.
MoonKid hat geschrieben:Wie und wo kommen hier die mount-Parameter ins Spiel? Was würden die an der Ansicht verändern?
Das wäre im Mount-Statement unterzubringen, hier als Beispiel etwa so:

Code: Alles auswählen

mount //10.10.1.2/PublicData /media/PublicData -t cifs  -o credentials=/home/thomas/.smbcredentials,uid=thomas,gid=sambauser,rw,nosuid,nodev,noexec,async
Das hat keinen Einfluss auf die tatsächlichen Rechte, wie sie vorliegen oder auf dem Server gesetzt werden, hier würde dann einfach bei Deinem ls-Befehl mein Name als User und die Group rauskommen.... die natürlich beide existieren. Und in der Gruppe Sambauser sind eben alle Familien-Mitglieder hinterlegt, die auf die Public-Dirs zugreifen dürfen. Also alle sehen hier das gleiche. Aber mal ehrlich, da hat noch nie einer drauf geachtet.... wenn die Daten zugänglich sind, sind alle zufrieden.... wem sie laut Linux gehören, interessiert hier keinen. *fg*
MoonKid hat geschrieben:Und kann man beim Anlegen eines Linux-Nutzers die UID eigentlich beeinflussen, um solche Dinge zu umgehen? z.B. könnte man ID-Räume
Ja, das geht alles. Den Ehrgeiz hatte ich zu Anfang auch.... ich wollte das wie unter Windows haben, alles schön synchron. Aber das ist eine solch sinnlose Arbeit, an der man bei jedem PC erneut anfängt, wenn man ihn neu aufsetzt. Sobald du nur irgendwie nicht die absolut gleiche Reihenfolge beim adduser bei der Einrichtung der User einhälst, knallt es... und dann fängt man an, systemweit die UIDs für alle Dateien zu kontrollieren und ggf von Hand zu korrigieren. Bis ich zu dem Schluss kam, dass ich einen an der Waffel hätte, wenn ich das weiter so mache *lacht* Vor allen Dingen braucht man das auch wirklich nicht. Auf dem Samba-Server werden bei mir generell alle Dateien auf öffentlichen Freigaben mit dem/der gleichen Standard User:Group gespeichert. Was die Clients nachher "oben" sehen, regelt das Mount-Statement. Die Dateien für die privaten Mounts werden allerdings mit dem/der usereigenen User:Group gespeichert. Soweit ich weiss, kann Debian auch die Synchronisation zwischen Client und Server, mit nem Domain-Controller oder wie auch immer... ich habe mich damit mangels Interesse nie befasst. Das was Debian und Samba onboard mitbringen, ist für mein lokales Netzwerk völlig ausreichend.... Fileserver (Private und Public-Daten), Printserver, VPN-Server, Medien-Server, Cloud-Server, Postfach-Server... das leistet alles mein kleiner Debian-Server.... und zwar völlig zufriedenstellend.
vg, Thomas

MoonKid
Beiträge: 510
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 28.01.2017 22:53:28

TomL hat geschrieben:Das wäre im Mount-Statement unterzubringen, hier als Beispiel etwa so:

Code: Alles auswählen

mount //10.10.1.2/PublicData /media/PublicData -t cifs  -o credentials=/home/thomas/.smbcredentials,uid=thomas,gid=sambauser,rw,nosuid,nodev,noexec,async
Das hat keinen Einfluss auf die tatsächlichen Rechte, wie sie vorliegen oder auf dem Server gesetzt werden, hier würde dann einfach bei Deinem ls-Befehl mein Name als User und die Group rauskommen.... die natürlich beide existieren. Und in der Gruppe Sambauser sind eben alle Familien-Mitglieder hinterlegt, die auf die Public-Dirs zugreifen dürfen.
Danke für deine ausführliche Beschreibung. Es wird langsam klarer.
Aber wenn ich mich jetzt hinsetze und eine smb.conf anlege und die Ordner auf dem Server, wird mir doch wieder schwindlig. Mir is nicht so ganz klar, welche der Ordner welche Rechte/Owner haben sollten. Vielleicht denke ich auch zu kompliziert?

Kleine Nebeninfo: Meine bisherigen Samba-Erfahrungen basieren auf einem QNAP-NAS bei dem man auf einer Web-Oberfläche eingies (aber leider nicht alles) einstellen konnte.

Mal ein stark vereinfachtes Beispiel:
Auf dem Server sollen alle Samba-Shares unterhalb von /mnt/raid/ liegen. Das wären
  • /mnt/raid/Multimedia
  • /mnt/raid/Wichtig
Samba-User media darf nur lesend auf Multimedia und sonst nix zugreifen.
Samba-User admin soll so eine Art Samba-Root-User sein. Der darf nahezu überall lesen und schreiben. Er hat aber keine root-Rechte auf der Samba-Maschine, sondern fungiert nur im Kontext der Samba-Shares als "mächtigster" User.

Muss ich diese Shares überhaupt explizit mit mkdir anlegen? Oder reicht es, wenn ich Samba passend konfiguriere und der legt mir die Shares dann schon passend an, falls sie noch nicht vorhanden sind?

Würde es Sinn machen das so auf dem Server anzulegen?

Code: Alles auswählen

drwxrwxr-x 1 admin admin  4096 Jan 20 00:29 Multimedia
Hier fängt mein Problem schon an. Others können lesend darauf zugreifen. Es sollte aber nur der Eigentümer/Gruppe UND media darauf lesen können.
Also gefühlt würde ich grundsätzlich Others nie Rechte auf ein Samba-Share geben. Naja und in der Samba-Conf gibts ja auch nochmal "Rechte". :roll:

TomL
Beiträge: 5211
Registriert: 24.07.2014 10:56:59

Re: Samba: User verstehen

Beitrag von TomL » 28.01.2017 23:53:28

Du solltest versuchen, es nicht so kompliziert wie möglich zu machen, sondern nur so kompliziert wie nötig. Und Du solltest nicht die Anwender so dermaßen kastrieren, dass sie das Netzwerk nachher nicht mehr nutzen und wieder lokal speichern. Ich setze stattdessen auf Transparenz, gute Unterweisung und Eigenverantwortung. Und dabei würde ich bei der Einrichtung des Netzes nach folgenden Kategorieren unterscheiden:

1. Admin-Shares - Bereiche und Verzeichnisse, die nur mir zugänglich sind.
Rechte: thomas:thomas
Install = rwx-rwx-...

Und die Platten an sich, deren Rechte aber (siehe unten) gesetzt sind, bezgl. meiner UID also unten mit höherer Priorität. Besondere Jobs wie z.B. Backups oder ich muss ein Profil reparieren ... das läuft dann halt unter "root"
HD_1
HD_2, usw..

2. Public-Shares - Bereiche und Verzeichnisse, die alle verwenden dürfen
Rechte: thomas:sambauser
Multimedia = rwx-rwx-...
DatenAlle = rwx-rwx-...
PublicMail = rwx-rwx-...

3. Private-Shares - Persönliche usereigene Bereiche
Rechte: username:thomas
Daten = rwx-rwx-...
Mail = rwx-rwx-...

Und darüber hinaus werden bei mir Netzlaufwerke generell nach der Prämisse geshared, dass vom Netzlaufwerk keine ausführbaren Programme möglich sind = nosuid,nodev,noexec

Für die smb.conf kann ich Dir auch einen Tip geben. Du solltest eine Default-Conf immer zu allererst einmal sichern, bevor Du etwas veränderst. Zum Beispiel hier mit dem Befehl:

Code: Alles auswählen

cp /etc/samba/smb.conf /etc/samba/smb.conf.original
Der bei mir als nächstes folgende Schritt ist dafür zu sorgen, die Conf auf ein übersichtliches Maß zu bringen, also alles unwirksame zu entfernen.... siehe unten. Und der dritte Schritt ist es dann, bevor ich das im System produktiv starte, mir die Bedeutung der wirksamen Parameter in der Conf klar zu machen. Und wenn es dazu Fragen gibt, dann würde ich mich an ein solches Forum wie hier wenden.... und zwar bevor ich das produktiv setze. Der m.E. falsche Weg ist es, wenn man auf die Frage "Warum druckt mein Drucker nicht?" erst mal gegenfragen muss "Bist Du sicher, dass du einen Drucker hast?" *lacht*
https://www.samba.org/samba/docs/man/ma ... onf.5.html

Code: Alles auswählen

[global]
   workgroup = WORKGROUP
   server role = standalone server
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   security = user
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = no
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = no
   map to guest = bad user
   usershare allow guests = yes
   invalid users = root
   
#======================= Share Definitions =======================

[homes]
   comment = Home Directories
   browseable = yes
   read only = no
   create mask = 0777
   directory mask = 0777
   force create mode = 660
   force directory mode = 770
   valid users = %S

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

[testshare]
  path=/media/testshare
  writeable = yes
  browseable = yes
  guest ok = no
  force create mode = 0777
  force directory mode = 0777
Die Public-Shares kriegen bei mir alle

Code: Alles auswählen

force user = thomas
force group = sambauser
create mask = 0660
directory mask = 0770
force create mode = 0660
force directory mode = 0770
Der (nur 1) Admin-Share

Code: Alles auswählen

force user = thomas
force group = thomas
create mask = 0660
directory mask = 0770
force create mode = 0660
force directory mode = 0770
Lediglich beim Anlegen der Mount-Points und der Binds auf dem Server muss man dann eben einmalig auch die Linux-Rechte passend setzen. Aber dran denken, je komplizierter Du das aufbaust, umso komplizierter ist es, wenn man bei einer neuen Platte alles reproduzieren muss. Einfache Strukturen, einfache Regeln - bei uns muss es nur wirksam für/gegen Laien und Familienmitglieder sein.

Letztendlich muss man bei solchen Sachen auch Backup-Strategien bedenken. Das heisst, das sollte nach Möglichkeit von allen Usern unbemerkt ablaufen und trotzdem sind alle Daten regelmäßig gesichert. Bei uns finden jeden Monat vom 1. bis 4. vier unterschiedliche Initial-Backups statt. Dann beginnend am 8., am 16. und am 24. jeweils über weitere 3 Tage weitere 3 inkrementelle Updates.... alles immer morgens um 5 Uhr. Das heisst, ich habe in einem rollierenden Verfahren immer 3 frühere Versionen. Darüber hinaus wandern von 3 USB-Platten so alle 4-8 Wochen rollierend eine ins Schließfach. Wenn da jetzt wirklich mal was passieren sollten, scherts mich echt nicht weiter. Aber solche Sachen solltest nur nicht so einfach in der Planung vergessen.
Zuletzt geändert von TomL am 03.02.2017 10:35:53, insgesamt 1-mal geändert.
vg, Thomas

MoonKid
Beiträge: 510
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 31.01.2017 15:48:04

Danke für die tiefen Einblicke in deine Config. ;)

Mein Grundgedanke ist der, dass ich hier einen Windows-Rechner/User im Netzwerk habe. Das NAS nutze ich auch als Backup-Medium. Der Windows-Rechner darf auf keinen Fall lesend/schreibend (z.B. wg. Verschlüsselungs-Trojanern) auf diese Bereiche zugreifen können. Deswegen bekommt der eigentlich seine eigenen Shares. Aber die Medien-Ordner (Musik, Videos) sollte er lesen können (dafür gibt es den User media), jedoch nicht schreiben.

Ohne GUI (wie z.B. im QNAP OS) ist es schwieriger da gedanklich rein zu kommen.

Ich setz mich dran...

TomL
Beiträge: 5211
Registriert: 24.07.2014 10:56:59

Re: Samba: User verstehen

Beitrag von TomL » 31.01.2017 19:15:58

Ist doch kein Problem, dann erstellst Du einfach 2 "binds" auf das MultiMedia-Verzeichnis. Das eine als reguläres mit normalen Rechten für normale Clients, und das zweite seitens Samba und Linux-Rechten mit Nur-Lesen-Rechten für die Windows-Clients. Und dann mountet der Windowsrechner eben den rechtelosen Share und fertig ist die Baustelle.

BTW:
Das ist nicht meine Config, sondern nur vereinfachtes Anschauungsmaterial .
vg, Thomas

MoonKid
Beiträge: 510
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 31.01.2017 20:28:54

TomL hat geschrieben:Ist doch kein Problem, dann erstellst Du einfach 2 "binds" auf das MultiMedia-Verzeichnis. Das eine als reguläres mit normalen Rechten für normale Clients, und das zweite seitens Samba und Linux-Rechten mit Nur-Lesen-Rechten für die Windows-Clients. Und dann mountet der Windowsrechner eben den rechtelosen Share und fertig ist die Baustelle.
Ui! Das war jetzt zu schnell. :D "binds"? Ich rate ins Blaue: Kann man abhängig von der Client-IP unterschiedliche Rechte für das gleiche Share setzen?

TomL
Beiträge: 5211
Registriert: 24.07.2014 10:56:59

Re: Samba: User verstehen

Beitrag von TomL » 31.01.2017 21:28:41

MoonKid hat geschrieben:Ich rate ins Blaue: Kann man abhängig von der Client-IP unterschiedliche Rechte für das gleiche Share setzen?
Nee, nicht unterschiedliche Rechte für den gleichen Share, sondern ZWEI Shares auf die gleiche Ressource mit unterschiedlichen Rechten. Schau Dir mal meinen Vorschlag für die Verzeichnisstruktur des Servers an:

Code: Alles auswählen

\
 +- bin
 +- boot
 +- dev
 +- home
    + goofy
      + daten                        Mountpoint für User-Daten
    + donald
      + daten                        dto.
    + lupo
      + daten                        dto.
 +- usr
 +- opt
 +- media                            Mountpoints des Servers + Sambashares
    + Install
    + DatenAlle
    + MultiMedia
    + MultiMediaRO                   Samba = Read Only
 +- usw.
   
 +- LanShares                        Tatsächliche (!) Datenverzeichnisse                  
    + Install                        Admin-Dateien wie Deb-Packs, Conf-BAKs, Settings, Dokus, etc. 
    + HomeDirs                       Persönliche 'private' User-Daten mit Zugriff nur für den User
      + goofy
        + daten
        + mail
      + donald
        + daten
        + mail
      + lupo
        + daten
        + mail
    + DatenAlle                      Gemeinsame "Arbeits"-Daten
      + Dirs nach Bedarf
    + MultiMedia                     
      + Filme
      + Buecher
      + Musik
Die Aufmerksamkeit gilt jetzt hier 3 wichtigen Verzeichnissen:
1. /home und die jeweiligen Userverzeichnisse,
die bei mir nicht die üblichen Shell-Unterverzeichnisse enthalten. Eigentlich sind es weitestgehend leere Verzeichnisse, weil die User sich ja hier nicht lokal anmelden, die aber den Mountpoint "daten" enthalten. Achtung, das ist NUR ein Mountpoint und KEIN Datenverzeichnis. Der Hintergrund ist, das Samba diesen Mountpoint auf dem Client passend zum User "bindet", das heisst, es sind keine userbezogenen Einstellungen notwendig, Samba regelt das perfekt über den Homedir-Share. Ich habe an dieser Stelle keine server-gespeicherten Profile eingerichtet, sondern habe tatsächlich nur Arbeits-Daten vorgesehen, also alles, was schwer reproduzierbar ist, oder nur mit sehr hohem Aufwand wiederherstellbar ist. Die normalen Home-Dir-Profile habe ich alle lokal gelassen, weil ich das Backup vom Server auf das wesentliche reduzieren will.

2. /LanShares,
welche die echten im Lan angebotenen Daten und Verzeichnisse an einer Stelle zentral speichern, auf die die User aber nicht direkt zugreifen können, sondern nur indirekt über die Mountpoints in /media. Das "alles zusammen gespeichert" ist später total praktisch, wenn man sich um die Datensicherung kümmert. Man muss nicht selektieren, sondern sichert einfach dieses Verzeichnis als Ganzes und kann sicher sein, nichts vergessen zu haben.

3. /media
enthält die Mountpoints, in welches die tatsächlichen Verzeichnisse ge'bind'et werden. Die Samba-Share-Einstellungen beziehen sich nicht auf die Original-Dirs in /LanShares, sondern auf diese Mountpoints in /media.

Und diese (hier manuellen) bind's stehen (iüS) in der fstab und werden automatisch beim Boot abgearbeitet. Ich habe die hier mal 'als manuell' eingefügt, um damit zu spielen und zu testen.

Code: Alles auswählen

mount --bind /LanShares/Install     /media/Install
mount --bind /LanShares/DatenAlle   /media/DatenAlle
mount --bind /LanShares/MultiMedia  /media/MultiMedia
mount --bind /LanShares/MultiMedia  /media/MultiMediaRO

mount --bind /LanShares/HomeDirs/goofy  /home/goofy/daten
mount --bind /LanShares/HomeDirs/donald /home/donald/daten
mount --bind /LanShares/HomeDirs/lupo   /home/lupo/daten
Ergänzender Hinweis:
- Beim MultiMediaRO-Share für den Windows-Client entweder "read only=yes" oder "writetable=no" in der smb.conf eintragen
- Beim Admin-Share "Install" würde ich "browsable=no" einstellen und die Rechte auf mich begrenzen, ebenfalls smb.conf.
- Wenn Du Dir einen "browsable=no"-Share direkt auf /LanShares einstellst, hast Du mit einem Griff Zugriff auf alles, Ausnahme=User-Dirs, dafür sind Root-Rechte notwendig, was m.E. aber auch unbedingt richtig ist.

Auf dem Client sieht dann der user-eigene Datenmount so aus, der von samba auf dem Server mit dem korrekten Homedir gemountet wird. Ich habe dazu jeweils usereigene "smbcredentials" verwendet. Natürlich muss dazu auf den Client-PC-User-Homedirs jeweils der MountPoint "SHome" bestehen, der Name kann aber auch beliebig anders sein. Ich mag nur gerne sprechende Namen.

Code: Alles auswählen

mount //10.10.1.2/homes/daten     /home/lupo/SHome        -t cifs  -o username=lupo,defaults
mount //10.10.1.2/homes/daten     /home/goofy/SHome       -t cifs  -o username=goofy,defaults
Probiers mal und guck, was geht oder nicht, oder denk drüber nach..... und frag, wenn was unklar ist....

Hth
vg, Thomas

MoonKid
Beiträge: 510
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 03.02.2017 00:00:53

(gelöst)
Hab jetzt ein bisschen rumgebastelt, aber kann mich nicht an meinen eigenen Shares anmelden.

Der User media ist in /etc/passwd vorhanden, er hat ein Home-Verzeichnis und ich kann mich auch lokal und sogar per SSH an der Maschine mit ihm anmelden.

Das relevante Share sieht so aus

Code: Alles auswählen

[Media]
path=/media/MediaRO
writeable = no
browsable = yes
guest ok = no
valid users = media ayako
write list = admin
Der relevante Abschnitt im log-file für den betreffenden Client sieht so aus

Code: Alles auswählen

[2017/02/02 23:42:36.330568,  2] ../source3/auth/auth.c:315(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [media] -> [media] FAILED with error NT_STATUS_NO_SUCH_USER
Ich bin in meinem Dateimanger (Thunar) über Windows-Netzwerk bis zum relevanten Verzeichnis durchgeklickt. Beim Anmeldedialog die passenden Daten (mehrmals!) eingegeben. Kein Erfolg. Keine Fehlermeldung. Auch smbclient gibt keine Fehler beim Verbindungsversuch aus. Er fragt das Passwort ab und zeigt mir dann alle Shares (so wie bei Option -L) und landet dann wieder auf der Bash.

Lösung: Ach natürlich muss man den User auch noch zum Samba-User machen. :facepalm: sudo smbpasswd -a <username>.

Antworten