staging.inyokaproject.org

Gibt es libpam-smbpass überhaupt noch? Ich hab bisher auch immer gesonderte Samba Benutzer angelegt bzw in die tdbsam DB geschrieben.

Max-Ulrich_Farber schrieb:

[…] Die Befehle smbclient -L bzw. smbtree bekommen vom Server nicht die gewünschten Informationen (Freigabenliste), wenn dort SMBv1 deaktiviert ist, […]

Das ist so nicht richtig. Zunächst einmal: smbclient und smbtree funktionieren völlig unterschiedlich, was eine separate Diskussion erfordert.

smbclient baut eine SMB-Verbindung zum angegebenen Ziel auf und benutzt dazu die Angaben auf der Kommandozeile, aus seiner Programmumgebung, in der Konfigurationsdatei /etc/samba/smb.conf und eingebaute Vorgaben. Dabei übersteuert stets eine im Vorsatz früher genannte Quelle die später genannten. Beim Verbindungsaufbau schickt es eine Liste der SMB-Protokolle, die es benutzen darf (nicht die es benutzen kann!) an den Server. Dieser entfernt aus dieser empfangenen Liste alle Protokolle, die er nicht kennt und alle, die er nicht benutzen darf und wählt dann aus der Restliste (sofern sie nicht leer ist) das höchste Protokoll aus und schickt das an den Anfragenden zurück. Die weitere Kommunikation erfolgt dann mit dieser Protokollversion, also immer der höchstem beiden Partnern aktuell verfügbaren (im Sinne von: darf benutzt werden) Version. Im Sonderfall, wenn die Restliste leer ist, gibt es eine Fehlermeldung und keine weitere Kommunikation. Biese Prozedur, welche schon Bestandteil des Protokolls war, als man es nicht SMB, sondern NetBIOS oder LAN-Manager nannte, habe ich mit „Aushandeln der Protokollversion“ gemeint.

smbclient -L … bezieht in der Regel die Freigabeliste per Version SMB3.11, so wie hier:

$ smbclient -N -L //lieselotte
Anonymous login successful

	Sharename       Type      Comment
	---------       ----      -------
	hello           Disk      user/group: Samba Client klaus/klaus - SMB3_11 - Server klaus/nogroup
	Videos          Disk      
	temp            Disk      
	IPC$            IPC       IPC Service (Client 192.168.178.44 - Server lieselotte 192.168.178.26)
	klaus.public    Disk      öffentliche Dateien von klaus
Reconnecting with SMB1 for workgroup listing.
Connection to lieselotte failed (Error NT_STATUS_CONNECTION_REFUSED)
Failed to connect with SMB1 -- no workgroup available
$

lieselotte ist ein Samba-Server, der den SMB-Teil der Protokoll-Version NT1 nicht spricht, sondern nur SMBv2 und höhere Versionen.

Der Client spricht zwar die alten Protokollversionen, benutzt sie aber nicht, weil besseres ausgehandelt wurde:

$ testparm -s -v | grep protocol
Load smb config files from /etc/samba/smb.conf
[…]
	client ipc max protocol = default
	client ipc min protocol = default
	client max protocol = default
	client min protocol = CORE
	server max protocol = SMB3
	server min protocol = SMB2_02
klaus@theophanu:~$ 

Erst wenn ich smbclient die Benutzung von SMBv3 verbiete, wird ein anderes Protokoll, aber wieder das in dieser Situation beste verwendet:

$ smbclient -N -L //lieselotte --option="client max protocol = SMB2"
Anonymous login successful

	Sharename       Type      Comment
	---------       ----      -------
	hello           Disk      user/group: Samba Client klaus/klaus - SMB2_10 - Server klaus/nogroup

smbtree benutzt dagegen das Protokoll SMB (Port 139/tcp (bei mir gesperrt!) oder 445/tcp) überhaupt nicht, sondern bezieht seine Informationen per NetBIOS-Name-Protocol (Broadcast an 137/udp), um die Workgroups und die dafür zuständigen Master-Browser-Server zu finden und erfragt dann die Freigabelisten vom jeweiligen Master-Browser-Server der Workgroup (Port 138/udp). Lediglich für diese Freigabelisten ist serverseitig das Protokoll SMBv1 erforderlich, mit der der Server seine Freigaben an den Master-Browser-Server veröffentlicht. Das sieht bei mir so aus:

$ smbtree 
[…]
	\\ROUTER         		Router
		\\ROUTER\IPC$           	IPC Service (Router)
		\\ROUTER\Router         	
	\\LIESELOTTE     		Client 0.0.0.0 - Server lieselotte 0.0.0.0
klaus@theophanu:~$ 

lieselotte spricht kein SMBv1 und kann daher seine Freigabe-Liste nicht an den Master-Browser-Server veröffentlichen, obwohl diese (s.o.) ja sogar über SMBv2/3 abfragbar wäre. ROUTER ist hier dagegen eine Fritzbox, welche NT1 als höchstes Protokoll beherrscht und dessen Freigabeliste hier verfügbar ist.

Dieser alte Mechanismus von smbtree ist übrigens das, was als Windows Netzwerk in der GUI angezeigt wird.

Und beim Mounten mit mount -t cifs ... erfolgt doch gar kein Aushandeln des Protokolls, falls die Option vers=... angegeben ist […]

mount.cifs ist eine von Samba unabhängige Implementierung des SMB-Protokolls, verhält sich aber bezüglich der Aushandlung der zu verwendeten Protokoll-Version natürlich genauso wie oben:

• Ohne Verwendung der Option vers=… benutzt die Software eine von seiner Programmversion abhängige Liste von zulässigen SMB-Versionen. Du hast diese zitiert. Der Server ermittelt die höchste gemeinsam verfügbare Version und schickt diese oder eine Fehlermeldung zurück.

• Mit Verwendung der Option z.B. vers=1.0 schickt mount.cifs diese Liste an den Server: „Ich spreche SMBv1 bis SMBv1.“ Der Server ermittelt wieder die höchste Version, die er und der potentielle Client beherrschen und schickt entweder NT1 oder eine Fehlermeldung zurück.

Jetzt zur Benutzer-Datenbank.

Dafür antworte ich separat.

Danke für diese tolle und ausführliche Antwort! 👍

Der Einfachheit halber fange ich einmal hinten an. Bei mount.cifs ist alles genau so, wie ich es mir vorgestellt habe.

Bei smbtree ist meine Darstellung offenbar unzulässig vereinfacht. Weil die Ermittlung der Freigaben-Liste über den Master-Browser läuft, handelt es sich um zwei Kommunikationen, die des Servers mit dem Master-Browser und die des Client mit demselben. Für die erste ist SMBv1 nötig, für die zweite nicht. Es ist also völlig richtig, dass keine direkte Kommunikation des Servers und des Client mit SMBv1 erfolgt, auch wenn es so aussieht. Das Beispiel ist von mir schlecht gewählt. Doch zum Glück ist dies ja für den Artikel hier irrelevant. Trotzdem danke für die Klarstellung!

Nun zu smbclient -L //<Servername>. Da habe ich vielleicht nicht alles ganz verstanden:

Reconnecting with SMB1 for workgroup listing.
Connection to lieselotte failed (Error NT_STATUS_CONNECTION_REFUSED)
Failed to connect with SMB1 -- no workgroup available

Das verstehe ich so (vielleicht falsch…): smbclient versucht als erstes mittels SMBv1 vom Server eine Freigaben-Liste zu erhalten. Doch

no workgroup available

könnte ja ein Hinweis sein, dass auch hier wieder – wie bei smbtree – zwei Kommunikationen im Spiel sind, und dass SMBv1 nur für die Kommunikation des Servers mit dem Master-Browser gebraucht wird. Die Kommunikation zwischen Server und Client erfolgt dann wieder mit dem höchsten zugelassenen (""kann" und "darf") Protokoll, also heute meist SMBv3.

Ich gebe mich also geschlagen. Die beiden Ausnahmen zu der Regel sind, genau genommen, keine. Sie sehen nur, oberflächlich betrachtet, so aus. Und wenn man die Einigung mittels der Information "ich spreche nur dies eine Protokoll" ebenfalls als "aushandeln" ansieht, dann ist auch mount.cifs kein Widerspruch.

Ich will jetzt sehen, dass ich die Formulierungen so ändere, dass jemand, der von Master-Browser, verschiedenen Implementierungen des SMB-Protokolls usw. keine Ahnung hat, etwas damit anfangen kann, und dass derjenige, der wie Du über die "Interna" Bescheid weiß, die Formulierungen nicht als falsch empfindet. Im Grunde braucht ja "Otto Normalverbraucher" nur die einzige Information "manches geht auch dann nicht ganz ohne SMBv1, wenn SMBv2/3 zur Kommunikation verwendet wird". Die Erklärung, wie und warum dies so ist, übersteigt die Aufgabe dieses Artikels.

Nun zur Samba-Datenbank. Da bin ich auf Deine Erklärung gespannt, denn dies ist für diesen Artikel ja wirklich relevant.

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

[…] Nun zu smbclient -L //<Servername>. Da habe ich vielleicht nicht alles ganz verstanden:

Reconnecting with SMB1 for workgroup listing.
Connection to lieselotte failed (Error NT_STATUS_CONNECTION_REFUSED)
Failed to connect with SMB1 -- no workgroup available

Das verstehe ich so (vielleicht falsch…): smbclient versucht als erstes mittels SMBv1 vom Server eine Freigaben-Liste zu erhalten. Doch

no workgroup available

könnte ja ein Hinweis sein, dass auch hier wieder – wie bei smbtree – zwei Kommunikationen im Spiel sind […]

Ja, es sind zwei völlig unabhängige Kommunikationsvorgänge:

1. Alles was ich geschrieben habe, bezieht sich auf die erste Kommunikation zur Abfrage der Freigabeliste.

2. Der zweite Kommunikationsvorgang beginnt mit der Ausgabe der Zeile „Reconnecting with SMB1 …“. Da macht dann smbclient etwas ähnliches wie smbtree und versucht eine Verbindung per IPv4 zu Port 139/tcp immer mit Protokoll Version 1. Meine Kommunikationsbeispiele sind allerdings dann im weiteren Verlauf untypisch, weil ich auf der Client-Seite Port 139 blockiere.

Ja, so scheint es zu sein.

Aber lassen wir jetzt das (komplizierte) Thema; es ist für den Normal-Benutzer nicht wichtig. Und weder smbtree noch smbclient sind hier direkt das Thema (indirekt schon, denn der Server wird immer angesprochen).

Aber die Samba-Datenbank ist es schon! Denn jeder Benutzer muss wissen: "Brauche ich die, und wenn ja, was muss ich machen?"

Bist Du mit der Straffung der "Persönlichen Freigaben", praktisch eine Reduktion auf einen Verweis zum Artikel net usershare, einverstanden?

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

[…] Bist Du mit der Straffung der "Persönlichen Freigaben", praktisch eine Reduktion auf einen Verweis zum Artikel net usershare, einverstanden?

Ja, die meisten Ausführungen wären m.E. im Artikel zu net usershare besser aufgehoben. Im Artikel zum Samba Server sollte m.E. verbleiben:

1. Solche persönlichen Freigaben sind möglich, werden aber nicht in der /etc/samba/smb.conf konfiguriert.

2. In der Datei /etc/samba/smb.conf kann eingestellt werden, welche Randbedingungen für solche Freigaben gelten. Dazu benutzt man die "net usershare"-Direktiven, deren Vorgaben so aussehen:

   $ testparm -s -v | grep usershare 
   Load smb config files from /etc/samba/smb.conf
   Loaded services file OK.
   Server role: ROLE_STANDALONE
   
   	usershare allow guests = Yes
   	usershare max shares = 100
   	usershare owner only = Yes
   	usershare path = /var/lib/samba/usershares
   	usershare prefix allow list = 
   	usershare prefix deny list = 
   	usershare template share = 

   Einzelheiten siehe Manpage.

3. Für jede persönliche Freigabe wird eine Datei im Verzeichnis /var/lib/samba/usershares/ angelegt, persönliche Freigaben anlegen darf, wer in dieses Verzeichnis schreiben kann, dies sind insbesondere die Mitglieder der Gruppe sambashare.

4. Verweis auf den anderen Artikel

Das Ganze natürlich geschmeidiger formuliert.

Max-Ulrich_Farber schrieb:

[…] Aber die Samba-Datenbank ist es schon! Denn jeder Benutzer muss wissen: "Brauche ich die, und wenn ja, was muss ich machen?"

Wir müssen erst einmal eingrenzen, über was wir reden:

1. Ubuntu 16.04 (das älteste noch unterstützte System) benutzt Samba 4.3, die aktuelleren Ubuntu-Varianten neuere Varianten bis hin zu Samba 4.11 bei Ubuntu 20.04. Alles, was bei Samba 3 und noch früher mal wichtig war, kann m.E. wegfallen bzw. ins Archiv.

2. Samba 4 ist ein sehr vielseitiges und umfangreiches Werkzeug. Die Möglichkeiten, welche es als Mitglied in einer AD-Domäne mitbringt, kann man in einem Wiki-Artikel nicht mal ansatzweise behandeln und ich überblicke diese großen Anwendungen auch nicht.

Was übrig bleibt, ist der standalone-Dateiserver für eine überschaubare Zahl benannter Benutzer, vielleicht 3 bis 100 oder auch 1000, aber keine zehntausende. Eben so hinreichend wenig, dass man sich die Verwaltung der Benutzer noch ohne Einrichtung einer Benutzer-Domäne mit speziellem Server als Domänencontroller zutraut.

Für solche standalone-Dateiserver komme ich ohne Verwendung des Befehls smbpasswd aus, auch wenn Windows-Clients (bisher getestet mit Windows 7) auf den Samba-Dateiserver zugreifen sollen. Dabei kann man Freigaben mit sowohl rein lesendem als auch schreibenden Zugriff gestalten und benötigt dafür lediglich:

• Konfiguration der Freigaben in der Datei /etc/samba/smb.conf

• das normale Unix-Benutzersystem mit /etc/passwd und /etc/shadow (oder ein anderes System)

• Verwaltung der Unix-Benutzerrechte in den Verzeichnissen, auf die per SMB-Freigabe zugegriffen wird

Beim Zugriff muss man natürlich den Benutzer auf dem Server und dessen Passwort angeben und diese müssen in der Unix-Benutzerdatenbank gefunden werden. Aber auch mit einer per smbpasswd verwalteten weiteren Benutzerdatenbank wäre das nicht anders.

Im Hintergrund werkelt Samba natürlich mit seiner tdb, aber selbst konfigurieren muss ich dafür lediglich einige Einstellungen in der /etc/samba/smb.conf, für welche aber auch schon Vorgaben mit kommen.

Ein wichtige Information für alle, die einen Samba-Server für mehr als 3 Benutzer betreiben, ist aber: Diese tdb sollte man in seiner Backup-Praxis berücksichtigen und mit den Datenbeständen der Freigaben sichern!

@ Persönliche Freigaben:

Ja, so hatte ich mir das ungefähr auch vorgestellt. Wird gemacht.

@ Samba-Datenbank:

• Ja, Samba 3 ist passé. Seit Ubuntu 14.04. Darauf wird nicht mehr eingegangen.

• Samba 4: "Die Möglichkeiten, welche es als Mitglied in einer AD-Domäne mitbringt" sind hier natürlich kein Thema. Da kenne ich mich auch gar nicht aus.

• "Für solche standalone-Dateiserver komme ich ohne Verwendung des Befehls smbpasswd aus" Da würde ich eben gerne wissen, wie Du das machst

  • erstellst Du Freigaben mit Gast-Zugang (public = yes oder guest ok = yes)? Dann brauchst Du natürlich kein smbpasswd. Wenn die UID zwischen Server und Clients synchronisiert sind, dann kannst Du über die UNIX-Extensions ganz mit den UNIX-Dateirechten arbeiten. Und mit den Windows-ACLs geht Ähnliches inzwischen ja auch. Man greift dann vom Client aus ohne Benutzernamen und Samba-Passwort zu, und es gelten (mit Einschränkungen) die Dateirechte wie auf dem Sever. Außerdem kannst Du ja in der smb.conf mit valid users und write list noch die Zugriffsrechte weiter einschränken. Das alles geht schon seit langem so. Oder

  • arbeitest Du vielleicht mit libpam-smbpass? Das gibt es tatsächlich nicht mehr, wenigstens in Ubuntu 20.04. Da davon bisher im Artikel nicht die Rede war, lassen wir das auch jetzt ganz weg.

Ich hatte bisher immer davon abgeraten, den Gast-Zugang zu benutzen und sich nur auf die UNIX-Extensions zu verlassen. Denn damit kann großes Ungedeih passieren, wenn die UID und GID nicht korrrekt synchronisiert sind. Man kann zwar seit einiger Zeit, glaube ich, die UIDs mappen, aber das habe ich noch nie gemacht. Und es ist ja auch nicht gerade einfach. Ein gut verschlüsseltes Passwort ist zehnmal sicherer als die ganzen UNIX-Extensions und Windows-ACLs. Und die POSIX-ACLs (UNIX/Linux) werden ja immer noch nicht unterstützt, das ist erst in Arbeit. Außerdem wurden bis SMBv2 nur der Samba-Benutzername und das Samba-Passwort verschlüsselt übertragen, alles andere unverschlüsselt. Erst seit SMBv3 ist eine komplette Verschlüsselung möglich.

Wenn man den Gast-Zugang verbietet (war bisher immer Standard-Vorgabe), dann musste man bisher immer zwei Vorgänge klar unterscheiden:

1. die Verbindung zum Server herstellen. Dafür brauchte man die Einträge in der Samba-Datenbank.

2. auf die eingebundenen Freigaben des Servers zugreifen. Dafür galten die Dateirechte und ACLs, zusätzlich eingeschränkt durch den Eintrag in smb.conf oder die ACLs von net usershare.

Wenn der Gast-Zugang erlaubt ist, dann braucht man für den ersten Teil keinen Benutzernamen und kein Passwort anzugeben. Der zweite Teil bleibt unverändert.

Oder gibt es inzwischen einen anderen, sicheren Weg, ohne smbpasswd zu arbeiten? Ich kenne keinen. Aber ich kenne auch bei weitem nicht alles in Samba!

Vielleicht sollte man im Text noch klarer unterscheiden: Vorgehen ohne Gast-Zugang und Vorgehen mit Gast-Zugang. Dann redet man auch nicht mehr an einander vorbei.

Gruß – Max-Ulrich

Ich denke nicht, daß kB den Gastzugang meint. Falls ja, wäre das imho keine gute Idee. Insbesondere wenn wir von mehreren Benutzern sprechen.

Samba wertet wohl per Default die passwd und shadow Datei aus, aber kann mit den (gehashten) Werten in der shadow Datei nichts anfangen, da Samba ein anderes Hash Verfahren durchführt. Deswegen muss meines Erachtens auch ein Benutzer in der Samba tdb (via smbpasswd) angelegt werden. Es gibt (gab?) wohl die Option Plaintext in der smb.conf für das backend der passdb. Damit soll dann direkt die shadow genommen werden ohne das Samba separat das Passwort hasht. Damit - und in Verbindung mit unix passwd sync - könnte man sich wohl die Benutzeranlage ersparen. Aber ob das in Samba 4 auch gilt, kann ich nicht sagen und müsste ich erstmal testen.

Mich würde auch interessieren, was kB gemeint hat.

Ich sehe schon, dieses Thema überschreitet meine Fachkenntnis und Kompetenz. Samba ist halt ein Wespennest!!

Ursprünglich war dieser Artikel ja nur bzw. überwiegend als Übersichtsartikel geplant gewesen; die einzelnen Themen sollten dann, soweit sie im Wiki überhaupt behandelt werden können, in einzelnen Artikeln abgehandelt werden. Doch manche Fragen sind halt von übergreifender Bedeutung, und so blähte sich der Artikel im Lauf der Zeit auf.

Es war nie meine Absicht gewesen, den Artikel jetzt umfassend neu zu bearbeiten. Das kann ich auch gar nicht. Deshalb ist der Artikel jetzt auch nicht in der Baustelle. Den einfacheren Artikel Samba Server GNOME musste ich neu bearbeiten, weil der einfach nicht mehr stimmte, schon länger. Und das zog nun – unbeabsichtigt – weitere Kreise. Für die beiden Artikel Samba Server GNOME und Samba Client GNOME reichen, so meine ich, meine Kenntnisse immer noch aus. Denn im professionellen Bereich wird ein Server niemals über die GUI aufgesetzt!

Ich möchte mich bei dem vorliegenden Artikel Samba Server nun gerne auf folgendes beschränken:

• veraltete Formulierungen, die nur für Samba 3 galten, entfernen oder verändern

• auf die unterschiedlichen Protokolle hinweisen, ohne dieses Thema grundlegend abzuhandeln (!)

• tote und hoffnungslos veraltete Links entfernen

• Doppel-Behandlungen, z.B. bei "Persönliche Freigaben", entfernen

Wenn Ihr, kB, chr123 und andere, mir dabei helft, bin ich froh. Doch damit soll es dann für mich genug sein. Alles übrige möchte ich jemand Jüngerem überlassen, der noch mitten drin steht in der Thematik (mein Berufsleben als Gymnasiallehrer ist seit 15 Jahren beendet), und von dem ich hoffe, dass er außer der fachlichen Kompetenz auch die Fähigkeit der einfachen Sprache besitzt.

Dass dem Artikel eine gründliche, umfassende Neubearbeitung gut tun würde, finde ich nach wie vor. Doch ich kann und will das nicht machen.

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

[…] Ich möchte mich bei dem vorliegenden Artikel Samba Server nun gerne auf folgendes beschränken:

• veraltete Formulierungen, die nur für Samba 3 galten, entfernen oder verändern

• auf die unterschiedlichen Protokolle hinweisen, ohne dieses Thema grundlegend abzuhandeln (!)

• tote und hoffnungslos veraltete Links entfernen

• Doppel-Behandlungen, z.B. bei "Persönliche Freigaben", entfernen

Den Plan finde ich gut.

Zur smbpasswd-Problematik: Die Sache wird auch für mich immer mysteriöser. Ich muss leider nach meinen aktuellsten Versuchen meine bisherigen Ausführungen zum Teil widerrufen und revidieren.

Fakt ist: Ich habe auf meinen Ubuntu-Systemen das Programm smbpasswd bisher nie benutzt, erst heute zur Aufklärung.

Dennoch habe ich auf meinen alten Systemen in der tdb von Samba solche Passwörter gefunden und diese sind essentiell für die Funktion. Wenn der Samba-Server in seiner tdb nicht den zum Benutzernamen passenden Rekord findet, misslingt die Anmeldung.

Meine Anregung, dass im Artikel das Thema Benutzerdatenbank optional wäre, ist also sachlich falsch und ich widerrufe das hiermit. Es tut mir leid, Euch damit unabsichtlich in Unruhe gebracht zu haben. Danke auch für Eure hartnäckigen Nachfragen. Ich habe dadurch viel gelernt.

Unklar bleibt, wie die Passworte bei mir in die tdb gelangt sind. Offenbar gibt es noch ein mir unbekanntes Helferlein, welches das im Hintergrund erledigt. Dieses Helferlein ist aber jedenfalls unzuverlässig, denn ich habe nur für einige, nicht für alle Benutzer solche SMB-Passwort-Records gefunden. Solange das nicht aufgeklärt ist, erscheint mir sinnvoller, bei der bisherigen Darstellung im Artikel zu bleiben. Es mag sein, dass der explizite Gebrauch von smbpasswd nicht immer erforderlich ist, aber es ist der sichere Weg.

Veraltet ist auf jeden Fall die Datei /etc/samba/smbpasswd zur Aufbewahrung der SMB-Passworte. Samba benutzt dafür jetzt seine tdb. Am praktischen Gebrauch des Programms smbpasswd ändert sich dadurch nichts.

Veraltet ist auf jeden Fall die Datei /etc/samba/smbpasswd zur Aufbewahrung der SMB-Passworte

Weiß ich, ist schon lange so.

Es tut mir leid, Euch damit unabsichtlich in Unruhe gebracht zu haben.

Macht nichts, so funktionieren fachliche Diskussionen 👍

Im vorwiegend für einfache Benutzer (keine Experten) gedachten Artikel Samba Server GNOME hatte ich so geschrieben:

Möchte man nur öffentliche Freigaben mit erlaubtem Gast-Zugang erstellen, sind keine weiteren Vorbereitungen nötig. Sollen aber auf diesen einzelnen Benutzern besondere Rechte (z.B. Schreibrecht) eingeräumt werden oder mittels Passwort geschützte Freigaben erstellt werden, dann muss zuerst für jeden berechtigten Benutzer ein eigener Samba-Account eingerichtet werden. Dies ist für jeden Benutzer möglich, für den auf dem Server ein System Account besteht. Wie ein solcher nötigenfalls eingerichtet werden kann, ist im Artikel adduser beschrieben.

Das muss ich noch etwas klarer ausdrücken "…ein solcher…" meint den System-Account. Ist an sich klar, denn der Samba-Account (smbpasswd usw.) ist im folgenden beschrieben. Ist die Formulierung abgesehen davon korrekt?

Offenbar gibt es noch ein mir unbekanntes Helferlein, welches das im Hintergrund erledigt.

Früher war eben libpam-smbpass so ein Heinzelmännchen, aber das gibt es ja nicht mehr. Ich hatte zuerst unix passwd sync im Verdacht, aber das synchronisiert nur in der umgekehrten Richtung. Außerdem ist no Standard. Braucht also nicht erwähnt zu werden. Bleibt mir also ein Rätsel!

Im übrigen bleibe ich dabei, vom Gast-Zugang eher abzuraten:

An important point is that if guest access is specified in the [homes] section, all home directories will be visible to all clients without a password. In the very unlikely event that this is actually desirable, it is wise to also specify read only access.

Gruß – Max-Ulrich

Ich habe das Wichtigste jetzt 'mal gemacht. Bitte lest den Artikel jetzt nochmal gründlich durch und kritisiert ihn, damit wir das Kapitel dann bald abschließen können. Hat mich ganz schön Zeit gekostet!

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

Ich habe das Wichtigste jetzt 'mal gemacht. Bitte lest den Artikel jetzt nochmal gründlich durch und kritisiert ihn

Mir sind aufgefallen:

1. Im einführenden Abschnitt führt der Link „Dokumentation“ zu einer Samba-3-Dokumentation.

2. Den Warnhinweis zu Gastzugängen auf Notebooks bzw. generell in Fremdnetzen kann man noch durch eine positive praktische Anleitung aufwerten: Den Zugriff von Gästen auf Freigaben kann man generell abschalten durch:

   map to guest = Never 

3. Zu „Die Rahmenbedingungen für alle Persönlichen Freigaben können in der Datei /etc/samba/smb.conf über verschiedene Parameter festgelegt bzw. verändert werden.“ gehört m.E. noch diese Anleitung für des Serververwalter: Die wirksamen Rahmenbedingungen für persönliche Freigaben kann man mit diesem Befehl anzeigen:

   testparm -s -v | grep usershare 

4. Statt des veralteten Befehls

   sudo service smbd restart 

   besser

   systemctl restart smbd.service 

   verwenden.

5. Veränderungen von im Netzwerk sichtbaren Namen und Beschreibungen erfordern oft den Neustart von nmbd.

Hat mich ganz schön Zeit gekostet!

Dafür verdient der Artikel jetzt aber auch die Auszeichnung: „Getestet für 20.04!"

map to guest = Never

Diesen Parameter hatte ich anders verstanden: Nur der User, der durch

guest account = xxx

spezifiziert ist, darf als Gast zugreifen, keine anderen User werden auf diesen gemappt. Standardmäßig ist das nobody. Ausprobiert habe ich das aber nicht. Kann ich noch machen.

Ich finde

map to guest = Bad User

für den Heimgebrauch sinnvoll (bei mir habe ich es auch so eingestellt). Den Gast-Zugang ganz verbieten möchte ich nicht; er gehört zu den Freiheiten, die Samba gestattet. Dass er per Default bei den einzelnen Freigaben abgeschaltet ist, genügt meines Erachtens. Man muss halt vorsichtig damit umgehen, dazu die Warnungen.

Die smb.conf wird (wurde früher?) übrigens ca. alle 90 Sekunden automatisch neu ausgelesen, d.h. die restarts der services sind wohl hauptsächlich für "Ungeduldige" und nicht so wichtig…

Die übrigen Anregungen arbeite ich noch ein. Gibt es sonst keine Fehler mehr? Dann ok für "getestet Focal"!

EDIT:

Habe 'mal die Anregungen eingearbeitet und "getestet Focal" eingetragen, obwohl noch nicht alle anderen Artikel, auf die verlinkt ist, diesen Getestet-Vermerk haben (z.B. net usershare). So kommt eines zum anderen… ☹