staging.inyokaproject.org

😳 Wer lesen kann, ist wie immer klar im Vorteil. 😳

Ich habe jetzt den Abschnitt Windows-ACLs in den Artikel eingefügt. Es handelt sich hierbei wohl um die wichtigste Neuerung in Samba-4, wenn man von der ganz neuen Möglichkeit, einen Samba-Server als Active Directory Domain Controller zu konfigurieren, mal absieht.

Eine Notwendigkeit von mehr Änderungen und Ergänzungen wegen Samba-4 sehe ich in diesem Artikel nicht. Für Hinweise bin ich aber immer dankbar.

Die Artikel Samba Winbind und Samba Server PDC müssen meines Erachtens gründlicher überarbeitet werden. Ich kann dies leider nicht machen.

Gruß – Max-Ulrich

Ich wünsche mir noch einen Redirect smb.conf → Samba_Server/smb.conf. Dieser wäre deshalb sinnvoll, weil die smb.conf nicht allein für Server, sondern auch für Clients relevante Optionen enthält.

Gruß – Max-Ulrich

Hallo,

Ich wünsche mir noch

Also Weihnachten und Ostern ist ja vorbei... trotzdem angelegt ☺

Gruß, noisefloor

Mein Geburtstag steht ja noch bevor 🙄 . – Danke!

Gruß – Max-Ulrich

Ich hatte schon Geburtstag (mal). Und ich wünsche mir, dass der Artikel für eine aktuelle Ubuntu-Version getestet wird 😀

Tote Links entfernt, Abschnitt Protokolle eingefügt, vor SMBv1 gewarnt. +Focal.

Gruß – Max-Ulrich

Anmerkungen zum Stand vom 25.05.2020:

• workgroup: 15 Byte, nicht 11 Zeichen. Halt ein SMB-Name.

• server string: Hier kann praktisch alles stehen, weil es nur ein Kommentar zum angezeigten Rechnernamen ist und außer der Anzeige keine funktionale Bedeutung hat. Das Schlimmste, was passieren kann ist, dass manche Bediener an Rechnern mit absonderlicher Zeichendarstellung eben altgallische Flüche sehen.

• "%h" ist ein SAMBA-Macro, hier wird eingesetzt: "the Internet hostname that Samba is running on" oder praktischer: Das was in der Datei /etc/hostname steht. Die Gefahr ist hier etwas subtiler: Man kann zwar den Rechnernamen fast beliebig nach den Regeln für DNS-Namen wählen, aber man sollte dabei die Regeln für SMB-Namen beachten, weil SAMBA den eigenen SMB-Namen aus dem Hostnamen ableitet. Wenn man den Hostnamen ungeschickt wählt, muss man in der /etc/samba/smb.conf einen SMB-Namen für den SAMBA-Server definieren; hier wird er aber als NetBIOS-Name geführt. Die Leute, die so etwas machen, werden zu Recht dafür bestraft, indem sie nun je nach Situation den Server mit unterschiedlichen Namen ansprechen müssen.

• WINS:

  • Die Einstellung wins support richtet sich an den SAMBA-Server, der per nmbd entweder als WINS-Server arbeitet oder nicht.

  • Die Einstellung wins server richtet sich dagegen nicht an den SAMBA-Server, sondern ausschließlich an die SMB-Clients, welche die Datei /etc/samba/smb.conf beachten und legt fest, welchen WINS-Server sie zur Namensauflösung benutzen sollen, wenn das denn so konfiguriert ist. (Konfiguriert wird das über name resolve order.)

  • Bitte diese beiden Einstellungen nicht gemeinsam behandeln, sondern 2 Abschnitte verwenden!

• Zugriffsberechtigungen für Freigaben: Es gibt etliche Einstellungen, die dafür verwendet werden können, manche haben auch noch Synonyme. Beispiele: read only, guest ok, browseable, write list usw. Alle diese können sowohl im Abschnitt [global] als auch in jeder Freigabe definiert werden. Die Wirkungsweise ist so, dass

  • die Definitionen in [global] die Vorgaben überschreiben, welche in SAMBA fest eingebaut sind

  • und die Definitionen im Abschnitt für die Freigabe individuell für diese Freigabe die geltende Vorgabe überschrieben.

• Zur Problematik des Suchens und Findens im "Windows Netzwerk" siehe meine gleichnamige Baustelle.

• Die Verwendung des Wortes „Heimnetz“ im Kontext der Protokoll-abhängigen Suche ist problematisch, weil Microsoft mit „Heimnetzgruppe“ eine spezielle Technik bezeichnet, welche garantiert nicht mit Linux zusammenarbeitet. Wurde eingeführt mit Windows 7 und bei einem Update von Windows 10 entfernt.

Danke, kB, für die ausführliche und informative Stellungnahme! 👍

Die Baustelle Windows Netzwerk kannte ich gar nicht. Schlimm, denn sie ist ja für die Thematik hier äußerst bedeutsam.

Mein Vorschlag: Du kümmerst Dich auch um smb.conf und ich ziehe mich da zurück. 😀 Dann können diese beiden Artikel optimal aneinander angepasst werden. Ich hatte ohnehin nie vor gehabt, den Artikel smb.conf zu überarbeiten. Ich wollte eigentlich nur die Protokoll-Optionen einfügen, von denen noch nichts drin stand. Und bei solch einer Gelegenheit findet man halt immer noch manches Andere, was nicht mehr aktuell ist…

Also kurz: Ich überlasse Dir den Artikel sehr gerne , ich bin nur froh darüber!!

Beim Testen bin ich noch auf ein anderes Problem gestoßen:

Vor Jahren schon wurde immer wieder bemängelt, dass offenbar die cifs UNIX extensions mit den inzwischen nicht mehr ganz neuen Protokollen SMBv2 und SMBv3 nicht mehr funktionieren. Bereits 2017 wurde darauf hingewiesen, dass die UNIX Extensions, welche die erweiterten POSIX-ACLs nicht erfassten, in SMBv3 von umfassenden POSIX extensions abgelöst werden sollten, die dann auch die POSIX ACLs unterstützen.

Wie man leicht feststellen kann, funktionieren die UNIX extensions in Samba 4.11.6 (Ubuntu 20.04) mit den Protokollen SMBv2 und SMBv3 nach wie vor nicht. Die POSIX extensions scheint es (noch) nicht zu geben; jedenfalls gibt es auf Client-Seite auch kein VFS, das sie unterstützt. Oder doch? Ich weiß von keinem.

Bei allen Klagen, die man massenhaft findet (auch zum nicht komplett funktionieenden Browsen mit GIO list), wird als Workaround empfohlen, das alte Protokoll SMBv1 wieder zu aktivieren. Etwas Besseres hat wohl Samba derzeit nicht zu bieten (??) Die Benutzer sind dann offenbar erleichtert, dass "es überhaupt läuft"

Ich setze mich dafür ein, nun endlich das veraltete, unsichere Protokoll SMBv1 aufzugeben, muss aber leider feststellen, dass Samba offenbar nach wie vor nur mit diesem Protokoll voll funktionsfähig ist. Soweit ich dies überhaupt beurteilen kann, sehe ich, dass die Protokolle SMBv2 und SMBv3 in Windows inzwischen bestens laufen und Standard sind. Wir beklagen uns, Samba (SMB) sei langsam und unsicher, "typisch Microsoft", und verwenden dabei ein uraltes Protokoll von 1983 - 1996, das Microsoft schon 2014 für "deprecated" und inzwischen für obsolet erklärt hat… Toll !

Beste Grüße Max-Ulrich