Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Nach dem "Ausflug" zum Artikel Samba Server habe ich nun am Artikel Baustelle/Samba Server GNOME weitergearbeitet. Dabei habe ich inhaltlich nichts mehr verändert, aber die Gliederung und vor allem viele Formulierungen gestrafft und (hoffentlich) präzisiert. Bitte schaut Euch den Entwurf kritisch durch. Gruß – Max-Ulrich
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: […] Bitte schaut Euch den Entwurf kritisch durch.
Aufgefallen sind mir diese Punkte im Abschnitt „Unterschiedliche Protokolle“ Im zweiten Abschnitt sind die Ausführungen zu den Parametern min protocol und max protocol zwar technisch richtig, ich schlage aber vor, ausschließlich die Schreibweisen server min protocol und server max protocol zu verwenden, da diese besser dokumentieren, was man meint. Technisch sind die Schreibweisen jeweils Synonyme. Der Satz „Doch nur mit dem Protokoll SMBv1 (cifs) stellt der Server dem Client eine Freigaben-Liste zur Verfügung, mittels deren dieser auf dem Server nach vorhandenen Freigaben suchen ("browsen") kann“ ist sachlich nicht richtig. Man kann sehr wohl mit den neueren Protokoll-Versionen ab SMBv2 Freigabelisten abfragen. Weiteres zu diesem Punkt folgt unten. Im dritten Abschnitt erscheint mir der Satz „Und Clients, die so konfiguriert sind, dass sie nur das Protokoll SMBv1 verwenden …“ praxisfremd. Ich habe jedenfalls schon lange keine SMB-Clients mehr erlebt, welche für den Zugriff auf Freigaben nur das Protokoll SMBv1 beherrschen, sehr wohl sind aber bis heute SMB-Server im Einsatz (z.B. Fritzbox!), welche nur SMBv1 kennen. Die Situation ist anders beim Durchsuchen von Netzwerk-Ressourcen!
Technischer Hintergrund zu Freigabe-Listen: Es gibt zwei technisch völlig unterschiedliche Methoden: Die direkte Methode befragt einfach den Server (dessen Namen man dafür natürlich kennen muss). Das ist das, was z.B. smbclient -N -L … macht und dies funktioniert mit jedem SMB-Protokoll von CORE bis SMBv3. Der Server antwortet mit der Freigabe-Liste. Aus Performance-Gründen ist die direkte Methode problematisch, wenn die Anzahl der Arbeitsstationen im Netz steigt. Deshalb hat man als Komfort-Dienst den Computer-Master-Browser erfunden. Alle SMB-Server im Netz einigen sich automatisch auf einen Rechner, der diese Aufgabe übernehmen soll. Nachdem er gewählt wurde, schicken alle SMB-Server ihre Freigabe-Listen an diesen Computer-Master-Browser. Dateimanager im Suchmodus (= „Windows Netzwerk“, „Netzwerkumgebung“ oder ähnlich benannt) auf der Client-Seite fragen dann gar nicht direkt die SMB-Server selbst an, sondern erbitten die Auskunft vom Computer-Master-Browser. Diese indirekte Methode ist bequem, schneller und performanter als eine Flut von direkten Anfragen, aber funktioniert leider nur bis SMBv1 alias NT1.
Damit der Computer-Master-Browser richtig funktioniert, ist notwendig, dass man alle Server und Arbeitsstationen in dieselbe Workgroup steckt. Leider ist das alleine nicht hinreichend. Zusätzlich müssen die SMB-Clients und die SMB-Server noch SMBv1 sprechen dürfen. Es ist aus meiner Sicht daher sinnvoll, dies den Clients zu erlauben: client min protocol = NT1 Die Clients verwenden das alte Protokoll ja nur, wenn nichts besseres ausgehandelt werden kann. Dagegen ist die ebenfalls für das Durchsuchen der Freigabe-Listen per indirekter Methode erforderliche Einstellung server min protocol = NT1 mit Sicherheitsrisiken verbunden. Aktuelle GUI-Dateimanager beherrschen offenbar nur die indirekte Suchmethode. Man darf also wieder einmal wählen zwischen funktionalem Komfort und sicherem Betrieb, kann aber z.Zt. nicht beides gleichzeitig haben. OT: Meine Katze sagt mir gerade nach Befragung meiner Glaskugel: Alle Bemühungen zur Abschaffung von SMBv1/NT1/CIFS werden erst dann Erfolg zeigen, wenn man ein Äquivalent für den Computer-Master-Browser bereitstellt, welches dann auch mit SMBv2/3+ kompatibel ist. Sie ist sich aber nicht ganz sicher, ob sie SMBv42 richtig verstanden hat.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Statt „überprüfen, ob der Name des Servers den Konventionen entspricht (maximal 15 Zeichen, …)“ hier besser: Byte Probleme entstehen z.B., wenn man Zeichen (z.B. ÄÖÜ) verwenden will, welche von den beiden Kommunikationspartnern unterschiedlich kodiert werden oder mit mehr als einem Byte dargestellt werden. „Ölkännchentülle“ enthält z.B. genau 15 Zeichen und ist auf einem System mit einem ein-Byte-Zeichensatz nach ISO-8859 ein gültiger SMB-Name, jedoch nicht auf einem System mit UTF-8-Zeichendarstellung, weil hier die drei Umlaute jeweils 2 Byte benötigen und der Name daher mit 18 Byte unzulässigerweise länger als 16 Byte wird.
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Man kann sehr wohl mit den neueren Protokoll-Versionen ab SMBv2 Freigabelisten abfragen.
Wie denn? Bei mir geht das nicht! Sollte es tatsächlich gehen (??), dann wäre manches Geschriebene falsch ☹ Die direkte Methode befragt einfach den Server (dessen Namen man dafür natürlich kennen muss). Das ist das, was z.B. smbclient -N -L … macht und dies funktioniert mit jedem SMB-Protokoll von CORE bis SMBv3. Der Server antwortet mit der Freigabe-Liste.
Nein, das tut der Server eben nicht – wenigstens bei mir nicht! Stelle ich auf dem Server ein server min protocol = NT1 , dann klappt alles. Stelle ich aber ein server min protocol = SMB2_02 (Default in Focal), bekomme ich keine Freigaben-Liste, sondern nur die Fehlermeldung: protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE Das heißt, ohne NT1 (SMBv1) geht es eben nicht. Ich wüsste gerne, wie Du es machst, dass es bei Dir klappt ❓ Auch die Einstellung des Client ist relevant. Stelle ich dort ein client min protocol = smb2_02 , bekomme ich auch keine Freigaben-Liste. Auf beiden, Client und Server, muss NT1 zugelassen sein. Was da intern geschieht, weiß ich nicht. Es ist hier auch nicht so wichtig, entscheidend ist das Ergebnis. Ich stelle mir das so vor, dass der Client versucht, "vorübergehend auf NT1 zurückzustufen"". Geht das, ist alles ok. Andernfalls Fehlermeldung und keine Liste. Auch wenn der tatsächliche Vorgang vielleicht komplizierter ist, diese Vorstellung entspricht dem Ergebnis… Meine Feststellung ist also: Weder die direkte noch die indirekte Methode funktioniert bei mir ohne NT1. Deshalb braucht man im Artikel auf die Unterscheidung der Methoden gar nicht einzugehen. EDIT: Sorry, sorry! kB hat Recht !! Ich nehme alles zurück. Die direkte Methode (ohne den Master-Browser zu bemühen) funktioniert! Ich hatte fälschlicherweise eingegeben smbclient -L -N … , und es muss heißen smbclient -N -L … , d.h die Reihenfolge der Parameter ist wichtig. Außerdem hatte ich ganz vergessen, dass ich auf meinem Laptop 'mal probeweise client max protocol = NT1 eingestellt hatte, um browsen zu können. Da geht natürlich mit server min protocol = SMBv2_02 gar nichts mehr. Wie kann man sich nur so dumm anstellen ? 😳 Jetzt habe ich wieder viel gelernt!
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: Man kann sehr wohl mit den neueren Protokoll-Versionen ab SMBv2 Freigabelisten abfragen.
Wie denn? Bei mir geht das nicht! Sollte es tatsächlich gehen (??), dann wäre manches Geschriebene falsch ☹
Dieses kleine Programm (bzw. smbclient) macht es: #! /bin/bash -e
# net-view zeigt Freigabelisten auch von SMBv2+ Servern
# (c) 2020 kB @ ubuntuusers.de
# *** gio list funktioniert nicht immer – Ursache unklar!
case $# in (0) set -- $(gio list smb:// ) ; esac
for workgroup
do echo ; echo $workgroup
for server in $(gio list smb://$workgroup )
do smbclient -N -L //$server |
grep -v -e Sharename -e'---' |
sed -n "/^\t/ { s_^\t_//$server/_ ; p }"
echo
done
done Es implementiert im Wesentlichen, was ich als direkte Methode bezeichnet habe, allerdings nicht perfekt. Vergleiche seine Ausgabe (auch im Zeitverhalten!) mit der von smbtree, welches die indirekte Methode benutzt. Wenn Du einen Server mit "server min protocol = SMB2 " im Netz hast, siehst Du die Unterschiede. Dies ist letzten Endes der Grund, warum Benutzer eines GUI-Dateimanagers auf Client- wie Server-Seite NT1 zulassen müssen, wenn sie komfortabel arbeiten wollen.
[…] Deshalb braucht man im Artikel auf die Unterscheidung der Methoden gar nicht einzugehen.
Ich möchte mich auf die triviale Aufgabe beschränken, die technischen Hintergründe darzustellen. Ich erwarte nicht, dass dies alles im Wiki-Artikel auftaucht und möchte sogar eher davon abraten. Und die schwierige Aufgabe, das trotzdem richtig, kurz und knapp und verständlich darzustellen, überlasse ich gerne Dir!
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Ich habe jetzt noch ein bisschen 'rumgespielt:
smbclient -N -L //<Server>/ und Dein Skript funktionieren, auch wenn auf dem Server und dem Client [client] min protocol = SMB2_02 eingestellt ist. Ich verstehe jetzt auch, warum.
gio list smb://<Server> funktioniert nur, wenn [client] min protocol = NT1 eingestellt ist, d.h. genau so wie beim Browsen mit dem Dateimanager
gio list smb://<Server/Freigabe> funktioniert nur, wenn die Freigabe mit gio mount smb://<Server/Freigabe> bereits eingehängt ist, dann aber unabhängig vom Protokoll
gio mount smb://<Server/Freigabe> funktioniert unabhängig vom Protokoll.
Das entspricht genau dem Verhalten der Dateimanager, d.h. diese verwenden offenbar gio list zum Browsen. Nicht überraschend. Ich denke, wenn man im Artikel schreibt, dass die vom Dateimanager verwendete Routine gio list… das Protokoll NT1 braucht (oder "verwendet"?), um vom Server eine Freigaben-Liste zu bekommen, dann ist das einfach und trotzdem nicht falsch. Warum das so ist, ist hier kein Thema. Und die bisherigen Aussagen sind leicht abzuändern: Statt "der Server stellt keine Freigaben-Liste zur Verfügung" schreibt man einfach "das GIO erhält vom Server keine Freigaben-Liste". Welche Rolle dabei der Master-Browser spielt, ist hier unwichtig. – Was meinst Du?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: […]
Ich denke, wenn man im Artikel schreibt, dass die vom Dateimanager verwendete Routine gio list… das Protokoll NT1 braucht (oder "verwendet"?), um vom Server eine Freigaben-Liste zu bekommen, dann ist das einfach und trotzdem nicht falsch. Warum das so ist, ist hier kein Thema. Und die bisherigen Aussagen sind leicht abzuändern: Statt "der Server stellt keine Freigaben-Liste zur Verfügung" schreibt man einfach "das GIO erhält vom Server keine Freigaben-Liste". Welche Rolle dabei der Master-Browser spielt, ist hier unwichtig. – Was meinst Du?
Finde ich gut!
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Habe jetzt die Formulierungen geändert. Eine pikante Einzelheit: Windows-Clients verwenden offenbar zum Anfordern der Freigaben-Liste nicht den Master-Browser; jedenfalls können sie auch auf dem Server browsen, wenn SMBv1 nicht zugelassen ist – und das sogar in einer Geschwindigkeit, die uns Linux-User neidisch macht! Ich habe dies mit Win-10 in einer VM ausprobiert. Deshalb musste ich die Einschränkung (nur hier markiert) anbringen: Also kann ab Ubuntu 20.04 LTS in der Standard-Einstellung kein Samba-Client durch Browsen auf dem Server Freigaben auffinden
Kein Ruhmesblatt für das GIO/GVFS! ☹ Es ginge offenbar auch anders. EDIT: Ich neige inzwischen dazu, diesen Sachverhalt als Fehler anzusehen. Wenn – auf dringenden Wunsch von Microsoft – das unsichere Protokoll SMBv1 nun endlich auch in Samba standardmäßig deaktiviert ist, müsste sich das GIO darauf einstellen, und das geht offenbar. Dass SMBv1 deprecated ist, weiß man schon seit Jahren, Zeit wäre also gewesen. Ich überlege mir einen Fehlerbericht wegen Inkompatibilität von GIO (GVFS) und aktueller Samba-Version. Wäre das sinnvoll?
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Das Folgende betrifft jetzt den Artikel Samba Client GNOME Gemäß den von kB erklärten und belegten Sachverhalten sind nun hier mehrere Formulierungen falsch: Der für das Arbeiten mit dem GVFS wichtigste Unterschied ist, dass aus Sicherheitsgründen mit den Protokollen SMBv2 und SMBv3 vom Server keine Freigaben-Listen mehr veröffentlicht werden.
Das stimmt so nicht. Nur das GIO bzw. GVFS erhält keine Freigaben-Listen, Windows schon. Und mit Sicherheitsgründen hat dies nichts zu tun! ist nicht nur unnötig, sondern kontraproduktiv! Das Ziel muss sein, SMBv1 jetzt möglichst weitgehend und bald dann ganz zu vermeiden. Für Windows-Clients ist das bereits möglich! – Kommt weg, statt dessen knapper Hinweis. Wird versucht die Verbindung mit einem höheren Protokoll aufzubauen, so erscheint statt dessen die etwas missverständliche Fehlermeldung ...
Ich war von folgender Aussage ausgegangen: Samba 4.8 changed default 'client max protocol' from NT1 to SMB3, together with fixes of Badlock, it broke browsing smb:// with default settings, because only NT1 (SMB1) protocol can browse network. Samba 4.10 made it possible to set min/max protocol version via libsmbclient API.
Ich habe jetzt noch einmal herumprobiert. Die Einstellung von client max protocol hatte keinen Einfluss auf das Browsen. Es kommt nur darauf an, dass auf dem Server und dem Client die Mindestprotokolle nicht höher als NT1 sind. Obige Aussagen sind anscheinend falsch (?). Was es für einen Sinn hatte, dass bis Samba 4.8 (also noch in Ubuntu 18.04) client max protocol = NT1 Standard war, weiß ich nicht. Ich kann mir momentan keinen sinnvollen Grund vorstellen. Ich meine mich dunkel zu erinnern, dass es da 'mal irgend einen Bug in der Implikation von SMB2 gab; vielleicht war das der Grund gewesen (??). Höchst seltsam. Das letzte "Problem" muss auch weg oder geändert werden.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: […] Deshalb musste ich die Einschränkung (nur hier markiert) anbringen: Also kann ab Ubuntu 20.04 LTS in der Standard-Einstellung kein Samba-Client durch Browsen auf dem Server Freigaben auffinden
Kein GUI-Samba-Client. smbclient kann es ja.
Kein Ruhmesblatt für das GIO/GVFS! ☹ Es ginge offenbar auch anders.
Jedenfalls ist momentan die Zusammenarbeit zwischen GIO und SAMBA suboptimal. Ich möchte aber nicht voreilig GIO beschuldigen, weil es auch an SAMBA liegen könnte: Möglicherweise ist SAMBA zu doof, um Freigabelisten per SMBv2+ an den Master-Browser zu melden. Ich weiß jetzt allerdings nicht, ob das technisch in der Protokoll-Version SMBv2 überhaupt vorgesehen ist. Vielleicht kann Microsoft das, aber SAMBA nicht? Das würde z.B. Deine Beobachtungen zum Zeitverhalten erklären. Ich werde mal versuchen, einen Master-Browser mit SMBv2 aufzusetzen.
[…] Ich neige inzwischen dazu, diesen Sachverhalt als Fehler anzusehen.
Ein Fehler oder ein fehlendes, aber dringend benötigtes Feature.
Ich überlege mir einen Fehlerbericht wegen Inkompatibilität von GIO (GVFS) und aktueller Samba-Version. Wäre das sinnvoll?
Ich meine: Ja!
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Kein GUI-Samba-Client. smbclient kann es ja.
Das weiß ich ja inzwischen. Da aber das Thema hier "Samba Client GNOME" ist, haben wir es wohl mit einer Zielgruppe zu tun, die zum Browsen ausschließlich den Dateimanager verwendet. Deshalb würde ich hier smbclient lieber gar nicht erwähnen. "Experten" werden wohl die Begrenztheit der Aussage erkennen, da im Satz davor ja von GIO die Rede ist. Ich werde mal versuchen, einen Master-Browser mit SMBv2 aufzusetzen.
Toll! 👍 Ich meine: Ja!
Könntest vielleicht Du das machen? Neben gründlicheren Informatik-Kenntnissen kannst Du sicher auch besser englisch! (zu meiner Schulzeit war hier französische Besatzungszone, und ich musste mir deshalb meine Englisch-Kenntnisse autodidaktisch erwerben…) Nochmal zum Master-Browser mit SMBv2: Das Browsen klappt mit einem Samba-Server (Version 4.11.6, min-protocol = smb2_02) und einem Windows-Client! Das heißt doch wohl, dass es nicht daran liegt, dass Samba die Freigaben-Liste nicht an den MB meldet, Windows aber schon. Der Unterschied ist der Client!
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Ich habe den Artikel Baustelle/Samba Client GNOME (Client !) nochmal gründlich umgemodelt (Gliederung) und viele Formulierungen geändert. Deshalb bitte ich darum, den Artikel erneut kritisch durchzusehen. Gruß – Max-Ulrich
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Ich rege an, dem Artikel noch den Tag Samba zu geben. Vielleicht wäre auch ein Verweis auf „Samba Client/Windows-Netzwerk“ sinnvoll? Dort wird u.a. ein Skript verfügbar sein, welches Nautilus ertüchtigt im Netzwerk (fast) so zu browsen und Netzwerk-Freigaben zu nutzen, wie man es von einer GUI erwartet. Dazu muss aber erst einmal die Baustelle „Samba Client/Windows_Netzwerk“ fertig werden.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: […] Ich werde mal versuchen, einen Master-Browser mit SMBv2 aufzusetzen.
Toll! 👍
Das Ergebnis meiner Versuche: Wer Master-Browser sein will, muss als SMB-Server SMBv1 sprechen. Jedenfalls, wenn der Master-Browser mit Samba realisiert wird. Die weiteren Konsequenzen stehen in meiner Baustelle.
[…] Der Unterschied ist der Client!
Soweit ich es nun nachstellen konnte, ist der einzige Unterschied zwischen einem auf gio aufsetzenden GUI-Dateimanager und anderen SMB-Clients: gio benutzt zur Abfrage der Freigabelisten nur SMBv1. Für alles andere, auch zum Einhängen der Freigaben, kann es neuere Protokolle verwenden und macht es auch, wenn der Server mitspielt.
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Das ist interessant, danke! Aber was bedeutet dies jetzt konkret: Soll ich die Warnungen vor SMBv1 relativieren, oder kann ich sie so stehen lassen, in der Hoffnung, dass irgendwann dann auch das Browsen ohne SMBv1 lückenlos funktionieren wird? Wenn ja, dann würde ich noisefloor darum bitten, jetzt die beiden Artikel Samba ... GNOME aus der Baustelle wieder zurückzuschieben. Damit dies zu einem Ende kommt. Den Artikel fstab lasse ich jetzt möglichst in Ruhe, d.h. ich korrigiere nur das, was offensichtlich falsch ist, und lasse es damit gut sein. Ähnlich mache ich es dann auch mit dem Artikel Samba Client cifs, an dem es ja nicht sehr viel zu tun gibt. Im Moment bastle ich an dem von noisefloor angefangenen Artikel gio, der dann den Artikel gvfs-mount (später dann gio mount) entlasten soll. Damit möchte ich mich dann aus dieser "Kampagne" wieder zurückziehen und die Hauptarbeit gern den Jüngeren überlassen. Beste Grüße Max-Ulrich Farber
|