ubuntuusers.de

😳 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

Trotz "getestet noble" ist der Artikel unbedingt noch ausbaufähig! Dies betrifft nicht allein, aber vor allem die seit Samba 4.23 standardmäßig vorhandenen SMB3-POSIX-Erweiterungen! Damit erübrigt sich (endlich) das veraltete SMBv1 völlig.

Ich habe jetzt die SMB3-POSIX-Erweiterungen getestet und möchte am Artikel folgendes vornehmen:

• Die Altlasten von smbv1 weiter zurückdrängen. Dieses Protokoll sollte generell nicht mehr verwendet werden.

• Den Abschnitt cifs-UNIX-Erweiterungen auf 3 Zeilen reduzieren und nur noch als Hinweis in den Abschnitt SMB3-POSIX-Erweiterungen einfügen. Die cifs UNIX extensions sind obsolet und extrem unsicher.

• Einen Abschnitt SMB3-POSIX-Erweiterungen verfassen, der im Umfang ungefähr dem früheren Abschnitt cifs-UNIX-Erweiterungen entsprechen wird, vielleicht ein bisschen mehr.

Ich bitte, den Artikel dafür für ca. 3-4 Wochen in die Baustelle zu verschieben. Wenn jemand noch weitere Aktualisierungen an dem Artikel vornehmen möchte, kann er gerne diese Gelegenheit nutzen.

Gruß Max-Ulrich_Farber

Max-Ulrich_Farber schrieb:

[…] Artikel dafür für ca. 3-4 Wochen in die Baustelle

Getan.

Ich bin jetzt so weit fertig und bitte um Hinweise für einen "Feinschliff".

Ich bitte zu beachten, dass es sich nicht um eine Neubearbeitung des ganzen Artikels handelt. Ich habe nur den Themenkomplex UNIX- bzw. POSIX-Extensions sowie Hard- und Symlinks neu verfasst, weil dieser Abschnitt absolut obsolet war und mir deshalb bei "getestet noble" am meisten Bauchweh verursacht hatte.

Aus meiner Sicht könnte der Artikel dann möglichst bald wieder zurück ins Wiki.

Max-Ulrich_Farber schrieb:

Ich bin jetzt so weit fertig

Vielen Dank für Deine Mühe.

Ich habe einige Typos ausgebessert und zur Verbesserung der Übersicht die formale Syntax optimiert.

[…] nicht um eine Neubearbeitung des ganzen Artikels handelt

Trotzdem eine Frage:

Im Artikel steht:

Dateifreigaben¶

Dateifreigaben, die durch einen Eintrag in fstab systemweit eingerichtet werden, nennt man im Gegensatz zu den mittels net usershare eingerichteten Persönlichen Freigaben auch Administrative Freigaben.

Da in der fstab gar keine Freigaben eingerichtet werden können, vermute ich hier einen Fehler. Möglicherweise ist "smb.conf statt "fstab" gemeint?

Danke für die Nacharbeit!

Weil das "große" Samba (nicht net usershare, das kleine "Samba für jedermann") seit Version 4 immer mehr auf Windows-Clients ausgerichtet wurde, fehlt es mir da inzwischen etwas an Kompetenz. Und mit den POSIX-Extensions hatte ich bei den Symlinks noch Probleme. Aber es waren auch nur die Samba-Versionen 4.19 und 4.22. Die Version 4.23 wird dann wohl erst mit Ubuntu 26.04 aktuell werden. Privat habe ich dann lieber noch NFSv4 parallel installiert, und das läuft wirklich stabil und problemlos.

Möglicherweise ist "smb.conf statt "fstab" gemeint

Ja, allerdings! Stammt der (alte) Fehler von mir? Dann Entschuldigung!