ArcaOS, Samba-Client und Win2000 sowie Win7
ArcaOS, Samba-Client und Win2000 sowie Win7
Bei einer Installation von ArcaOS 5.0.1 wurde der Samba-Client (NDFS32 Version 3.028 mit Netdrive-Plugin NDPSMB.DLL Version 3.00.x, ArcaMapper 2.6-beta) ebenso mit installiert.
Alle Versuche, mit dem ArcaMapper Verbindungen zu einem Win2000-Laufwerks-Resourcen herzustellen, scheiterten. Mehr als die "browsable"-Darstellung unter "Network neighborhood" gelingt nicht. Wählt man dort eine Laufwerks-Freigabe, erscheint bei "mount" jeweils "SYS0058: The specified server cannot perform the requested operation.".
Beim entsprechenden Versuch des Zugriffs auf Win7-Resourcen (SP1) zeigte sich nicht einmal die Darstellung im Resourcen-Browser.
Ist jemandem schon ein Zugriff auf Win2000- und Win7-Resourcen in dieser Konstellation gelungen? Es sollte doch möglich sein, unter ArcaOS auch auf Netzwerk-Laufwerke dieser Windows-Systeme zuzugreifen. Wie ist das zu schaffen?
Alle Versuche, mit dem ArcaMapper Verbindungen zu einem Win2000-Laufwerks-Resourcen herzustellen, scheiterten. Mehr als die "browsable"-Darstellung unter "Network neighborhood" gelingt nicht. Wählt man dort eine Laufwerks-Freigabe, erscheint bei "mount" jeweils "SYS0058: The specified server cannot perform the requested operation.".
Beim entsprechenden Versuch des Zugriffs auf Win7-Resourcen (SP1) zeigte sich nicht einmal die Darstellung im Resourcen-Browser.
Ist jemandem schon ein Zugriff auf Win2000- und Win7-Resourcen in dieser Konstellation gelungen? Es sollte doch möglich sein, unter ArcaOS auch auf Netzwerk-Laufwerke dieser Windows-Systeme zuzugreifen. Wie ist das zu schaffen?
Zuletzt geändert von hneubert am Mo 21. Aug 2017, 00:37, insgesamt 1-mal geändert.
Zufällig gestern hatte ich bei meinem ersten ArcaOS5.01-Versuch das gleiche Problem. Geholfen hat hier (Win10):
- im (ich glaube das hieß:) Win-Arbeitplatznetzwerk muss die Netzwerkerkennung freigegeben sein
- im Win-Netzwerk-Adapter IPv6 abschalten. Und dort Reboot.
Ob dies der Weisheit letzter Schluss war, keine Ahnung. Aber hat wenigstens hier funktioniert.
Voraussetzung natürlich, dass die "üblichen" OS/2-seitigen Einstellungen korrekt sind (\MPTN\BIN\setup.cmd), wovon ich mal ausgehe.
- im (ich glaube das hieß:) Win-Arbeitplatznetzwerk muss die Netzwerkerkennung freigegeben sein
- im Win-Netzwerk-Adapter IPv6 abschalten. Und dort Reboot.
Ob dies der Weisheit letzter Schluss war, keine Ahnung. Aber hat wenigstens hier funktioniert.
Voraussetzung natürlich, dass die "üblichen" OS/2-seitigen Einstellungen korrekt sind (\MPTN\BIN\setup.cmd), wovon ich mal ausgehe.
Habe hier ArcaOS5.0.1 installiert. Über die Arcamapper-Connections werden alle im Netz verfügbaren Computer, es sind drei Notebooks mit Win10, angezeigt. Um auf Laufwerke zugreifen zu können, müssen diese unter Win freigegeben werden. Mehr habe ich nicht gemacht, und es funktioniert bestens!
Gruß
Damon
Gruß
Damon
Das war zufällig der Bringer hier gestern. Eigentlich spielt "IPv6 an" bei meiner eCS-VM und ArcaOS5.0-VM keine Rolle; deshalb heute ein neuer Versuch mit in Win10 wieder aktiviertem IPv6 --- und wie von Zauberhand funktionierten auch in ArcaOS5.01 alle Samba-Zugriffe trotzdem wie gewünscht. So lieben wir "Praxis"LotharS hat geschrieben: - im Win-Netzwerk-Adapter IPv6 abschalten.
![Überglücklich :D](./images/smilies/icon_e_biggrin.gif)
Der Trick mit "IPv6 aus" war mir einmal an anderer Stelle entgegengekommen (aber wo und wann nur?...) und hatte mich dessen schwach erinnert. Ein Versuch war's immerhin wert und hatte nichts zerstört
![Lächeln :)](./images/smilies/icon_e_smile.gif)
Nachtrag, nachdem das gleiche Problem wieder an anderer Stelle auftauchte und wieder verschwand: Ich vermute, irgendwie hatten sich einige IP-Zuordnungen von DHCP vorübergehend ineinander verheddert. Fast kein Wunder bei der Installier-Fummelei
![Zwinkern ;)](./images/smilies/icon_e_wink.gif)
Zuletzt geändert von LotharS am Di 22. Aug 2017, 22:09, insgesamt 1-mal geändert.
Zur "Praxis": eigenartigerweise ist einen Tag danach auch bei mir die Sache mit Win7 auch gelaufen.LotharS hat geschrieben:... deshalb heute ein neuer Versuch mit in Win10 wieder aktiviertem IPv6 --- und wie von Zauberhand funktionierten auch in ArcaOS5.01 alle Samba-Zugriffe trotzdem wie gewünscht. So lieben wir "Praxis"![]()
Aus den Meldungen der "quasselnden VREXX-Console" vom ArcaMapper meinte ich nach diversen Mapping-Versuchen entnommen zu haben, dass der Win7-Host-Rechner, der die Laufwerks-Resourcen bereitstellt, keine erneuten Verbindungen mehr zulässt. Nach Neustart sind die gleichen Schritte dann ordentlich durchgelaufen. Mal sehen, ob das weitere Tage reibungslos abläuft und auch mit anderen Hosts zusammenarbeitet ...
Nebenbei:
Wie ist denn die Performance des Samba-Clients bei anderen Umgebungen?
Habe hier ArcaOS zum Test in der Oracle VirtualBox (virtuell 1 CPU) mit einem als Netzwerkbrücke betriebenen virtuellen Netzwerk-Adapter "PCNet Fast III (Am79C973)" getestet auf einem Win10-Host (Intel core i5/3,2 GHz, 4 Kerne). Zugriffe auf die ausserhalb der virtuellen Box liegenden Samba-Resourcen (z.B. rekursive Verzeichnisanzeigen, Kopieroperationen) zeigen immer sofort hohe Systemlast in der VirtualBox-Sitzung, damit dann auch relativ geringe Datentransferraten. Wenn man damit im "Echtbetrieb" ein paar 100 MB verarbeiten will, ist das schon um ein Vielfaches langsamer gegenüber entsprechende Operationen nativ vom Win10-Host aus.
Kann man die Virtualisierung hier optimieren, damit nicht so hohe CPU-Last benötigt wird - oder ist der Samba-Client auch nativ betrieben "nicht der schnellste"?
Wie ist denn die Performance des Samba-Clients bei anderen Umgebungen?
Habe hier ArcaOS zum Test in der Oracle VirtualBox (virtuell 1 CPU) mit einem als Netzwerkbrücke betriebenen virtuellen Netzwerk-Adapter "PCNet Fast III (Am79C973)" getestet auf einem Win10-Host (Intel core i5/3,2 GHz, 4 Kerne). Zugriffe auf die ausserhalb der virtuellen Box liegenden Samba-Resourcen (z.B. rekursive Verzeichnisanzeigen, Kopieroperationen) zeigen immer sofort hohe Systemlast in der VirtualBox-Sitzung, damit dann auch relativ geringe Datentransferraten. Wenn man damit im "Echtbetrieb" ein paar 100 MB verarbeiten will, ist das schon um ein Vielfaches langsamer gegenüber entsprechende Operationen nativ vom Win10-Host aus.
Kann man die Virtualisierung hier optimieren, damit nicht so hohe CPU-Last benötigt wird - oder ist der Samba-Client auch nativ betrieben "nicht der schnellste"?
Das könnte eine Antwort sein, wenn Arcanoae richtig gemessen hat.
In VBox habe ich "Intel Pro/1000 MT Desktop", in der VM den MMLEM-Treiber. Läuft
Die standardmäßig angebotenen Einstellungen könnten dann als Fallback dienen, laufen ja auch.
In VBox habe ich "Intel Pro/1000 MT Desktop", in der VM den MMLEM-Treiber. Läuft
![Lächeln :)](./images/smilies/icon_e_smile.gif)
Die standardmäßig angebotenen Einstellungen könnten dann als Fallback dienen, laufen ja auch.
- HerwigB
- Beiträge: 57
- Registriert: Mo 23. Dez 2013, 06:39
- Wohnort: Sankt Veit an der Glan
- Kontaktdaten:
Guten Morgen,
grundsätzlich:
1.) Samba Client an Win2000, WinXP, Win Vista, Win7 und Win10 ist getestet und funktioniert.
2.) Es ist egal ob IPv6 aktiviert oder deaktiviert ist, zumindest im IPv4 Netz (mit IPv6 wurde nicht getestet).
3.) Diverse Sicherheitseinstellungen sowohl bei Samba als auch bei Win wurden im Laufe der Zeit immer rigider, allerdings nicht im Gleichschritt. Das bewirkt, dass manche Verbindungen mit einer neuen Version auf einer der beiden Seiten plötzlich nicht mehr out of the box funktionieren. Da kann man sich nur anschauen, was wo konkret geändert wurde und die Konfiguration anpassen.
4.) Dynamische IPs am "servierenden" Rechner sind nie eine gute Idee (Caching an verschiedenen Stellen kann zu sehr seltsamen Problemen führen).
5.) Logs, logs, logs: Samba liefert super gute logs (im Gegensatz zu vieler andere Software). Zum Anfangen ist ein log level 5 logfile ok, ists hartnäckiger log level 10 einstellen (Achtung, seeeehr große logs!).
6.) Ticket in unserem Samba Tracker: Immer mit log, bitte, und wir bitwiser schauen uns das an.
grundsätzlich:
1.) Samba Client an Win2000, WinXP, Win Vista, Win7 und Win10 ist getestet und funktioniert.
2.) Es ist egal ob IPv6 aktiviert oder deaktiviert ist, zumindest im IPv4 Netz (mit IPv6 wurde nicht getestet).
3.) Diverse Sicherheitseinstellungen sowohl bei Samba als auch bei Win wurden im Laufe der Zeit immer rigider, allerdings nicht im Gleichschritt. Das bewirkt, dass manche Verbindungen mit einer neuen Version auf einer der beiden Seiten plötzlich nicht mehr out of the box funktionieren. Da kann man sich nur anschauen, was wo konkret geändert wurde und die Konfiguration anpassen.
4.) Dynamische IPs am "servierenden" Rechner sind nie eine gute Idee (Caching an verschiedenen Stellen kann zu sehr seltsamen Problemen führen).
5.) Logs, logs, logs: Samba liefert super gute logs (im Gegensatz zu vieler andere Software). Zum Anfangen ist ein log level 5 logfile ok, ists hartnäckiger log level 10 einstellen (Achtung, seeeehr große logs!).
6.) Ticket in unserem Samba Tracker: Immer mit log, bitte, und wir bitwiser schauen uns das an.
Bedeutet dies, daß die Verträglichkeit mit Windows 2000 Server, Windows Server 2003, 2003 R2, 2008, 2012 oder 2016 überhaupt nicht getestet wurde?HerwigB hat geschrieben:Guten Morgen,
grundsätzlich:
1.) Samba Client an Win2000, WinXP, Win Vista, Win7 und Win10 ist getestet und funktioniert.
Warum fragst Du das Herwig und nicht die von Dir dafür beauftragten IBM-Mitarbeiter?ak120 hat geschrieben: Bedeutet dies, daß die Verträglichkeit mit Windows 2000 Server, Windows Server 2003, 2003 R2, 2008, 2012 oder 2016 überhaupt nicht getestet wurde?
Zuletzt geändert von aschn am Mi 23. Aug 2017, 18:26, insgesamt 1-mal geändert.
Andreas Schnellbacher
Obwohl demnach nicht "offiziell" getestet: tut hier auch an Linux MInt 17.3 (Samba 4.3.x).HerwigB hat geschrieben: 1.) Samba Client an Win2000, WinXP, Win Vista, Win7 und Win10 ist getestet und funktioniert.
Btw.: Ihr akzeptiert hoffentlich notfalls auch Tickets für "ungetestete" Server, vorausgesetzt man besitzt tatsächlich ArcaOS (statt nur drüber zu reden) und kann damit Client-Logs erzeugen?
![Zwinkern ;)](./images/smilies/icon_e_wink.gif)
Stimme zu. Ausnahmsweise hatte ich diesmal als "Server" mein Notebook genommen, mit IP von DHCP, und darauf eine Art "Demo-VM" installiert. Im Prinzip funktioniert die Verbindung ins gesamte Heimnetz (egal ob im Host IPv6 an/aus) immer noch. Aber irgendwie hatte ich mit meinem Gefummel die Fritzbox zu sehr verwirrt, anscheinend mit IP-Salat als (vorübergehende) Folge. Meine Desktop-VMs haben alle feste IPs.4.) Dynamische IPs am "servierenden" Rechner sind nie eine gute Idee (Caching an verschiedenen Stellen kann zu sehr seltsamen Problemen führen).
Jedenfalls Danke für Deine gute Zusammenfassung.
Manche "Probleme" sitzen halt vor dem Bildschirm und erledigen sich manchmal wundersam.
![Lächeln :)](./images/smilies/icon_e_smile.gif)
Danke für die sehr ausführliche Stellungnahme!HerwigB hat geschrieben:...
grundsätzlich:
1.) Samba Client an Win2000, WinXP, Win Vista, Win7 und Win10 ist getestet und funktioniert.
2.) ...
6.) Ticket in unserem Samba Tracker: Immer mit log, bitte, und wir bitwiser schauen uns das an.
Da gibt es Sinn, sich weiter mit dem Samba Client weiter zu beschäftigen.
Noch zum Verständnis: Kann mit dem Samba Client auch (problemlos?) auf Resourcen zugegriffen werden, die auf Installationen von OS/2 Warp 4/3/eCSArcaOS2 mit dem alten IBMPEER bereitgestellt werden?
ArcaMapper scheint zumindest ein paar Ungereimtheiten zu haben.
Wird z.B. bei Tab "New Resource" von der einen Mount-Methode auf eine andere umgeschaltet, sind die vorherige Eingaben in den restlichen Eingabefeldern (Server, Share, Workgroup) teilweise schonmal verloren oder es stehen übernommene Feldinhalte einfach in unzutreffenden Feldern. So geht der Arbeitsgruppen-Name oft komplett verloren (ist etwas nervig, wenn man diesen wiederholt eintippen muss), "Share"-Namen stehen schon mal im Feld "Server" etc.
Bestimmt gibt es die Möglichkeit einer einfachen "Batch-Datei", mit der man Kommandos in der Art
net MEINEWG=TESTWORKGROUP
net use x: \\PC1\D$
net use y: \\PC2\E$
net use lpt2 \\PC3\LASER1
reihenweise eintragen und dann wiederholt und funktionssicher ablaufen lassen kann - ggf. Aufruf über STARTUP.CMD, geht dies etwa über SMBCLIENT.EXE? Wäre dankbar, wenn jemand einen kurzen Hinweis geben könnte, wo man sich weiter einlesen könnte.
Ernüchternde Erkenntnis:
Bei einem Test, via Samba-Client (unter ArcaOS 5.0.1 in VirtualBox laufend) Resourcen auf einem Win7-PC zu benutzen, entsteht sehr schnell ein Konflikt, der reibungslosen Programmablauf im Netzwerk verhindert.
Anstatt das der Samba-Client _eine_ SMB-Sitzung zum Win7-PC aufbaut und unter dieser der Reihe nach die Datendateien öffnet, werden vom gleichen Programm (EXE-Datei mit zahlreichen DosOpen()-Aufrufen) offensichtlich _mehrere_ SMB-Sitzungen aufgebaut, in welchen jeweils _eine_ Datei offen ist. Schnell ist so das Limit von 20 SMB-Sitzungen erreicht und ein geordneter Programmablauf nicht mehr möglich.
(Wie) Kann der Samba-Client konfiguriert werden, dass nicht in einer OS/2-Sitzung sinnlos zahlreiche SMB-Sitzungen geöffnet werden?
Wenn man Anhaltspunkte hätte, ob das festgestellte Verhalten nur in Zusammenhang mit der Virtualisierung auftritt (NW-Karte wird im Brückenbetrieb genutzt), könnte man ggf. in Richtung native Installation nachdenken, was aber wieder sehr aufwändig ist und nur bei reellen Erfolgschancen Sinn gibt ...
Bei einem Test, via Samba-Client (unter ArcaOS 5.0.1 in VirtualBox laufend) Resourcen auf einem Win7-PC zu benutzen, entsteht sehr schnell ein Konflikt, der reibungslosen Programmablauf im Netzwerk verhindert.
Anstatt das der Samba-Client _eine_ SMB-Sitzung zum Win7-PC aufbaut und unter dieser der Reihe nach die Datendateien öffnet, werden vom gleichen Programm (EXE-Datei mit zahlreichen DosOpen()-Aufrufen) offensichtlich _mehrere_ SMB-Sitzungen aufgebaut, in welchen jeweils _eine_ Datei offen ist. Schnell ist so das Limit von 20 SMB-Sitzungen erreicht und ein geordneter Programmablauf nicht mehr möglich.
(Wie) Kann der Samba-Client konfiguriert werden, dass nicht in einer OS/2-Sitzung sinnlos zahlreiche SMB-Sitzungen geöffnet werden?
Wenn man Anhaltspunkte hätte, ob das festgestellte Verhalten nur in Zusammenhang mit der Virtualisierung auftritt (NW-Karte wird im Brückenbetrieb genutzt), könnte man ggf. in Richtung native Installation nachdenken, was aber wieder sehr aufwändig ist und nur bei reellen Erfolgschancen Sinn gibt ...
Zuletzt geändert von hneubert am Do 24. Aug 2017, 19:41, insgesamt 1-mal geändert.
Oder vielleicht auch hier SMB-Sitzungen auf "Server-Seite"LotharS hat geschrieben: Nachtrag, nachdem das gleiche Problem wieder an anderer Stelle auftauchte und wieder verschwand: Ich vermute, irgendwie hatten sich einige IP-Zuordnungen von DHCP vorübergehend ineinander verheddert. Fast kein Wunder bei der Installier-FummeleiIch habe mal die Fritzbox ein wenig aufgeräumt, und hoffentlich Ruhe ist...
![Erschüttert :shock:](./images/smilies/icon_eek.gif)
Zuletzt geändert von hneubert am Do 24. Aug 2017, 19:51, insgesamt 1-mal geändert.
Neinbestimmtnicht.hneubert hat geschrieben: Oder vielleicht auch hier SMB-Sitzungen auf "Server-Seite"
![Lächeln :)](./images/smilies/icon_e_smile.gif)
Die Virtualisierung ist schuldlos (es sei denn, man hat die VM-Netzwerkverbindung sowieso nicht richtig konfiguriert; einfacher "ping" wäre erste Prüfmaßnahme, sodann "ipconfig" in Win, \mptn\bin\setup.cmd,...). Hier laufen unterschiedliche VMs mit Samba-Clients und sogar -Servern, alles nach Einrichten sauber.
War mir auch schonmal beim "Ausprobieren" passiert. Seitdem achte ich immer darauf, jede Verbindung pro Ressource nur 1mal herstellen zu lassen (notfalls wieder Unmount bzw. Detach) und prüfe die kleinen nbc-Dateien auf Plausibilität. Sehe ich daher nicht zwingend als "Software-Bug", wo _ich_ der Verursacher war.Anstatt das der Samba-Client _eine_ SMB-Sitzung zum Win7-PC aufbaut und ...
Beispiel:
- Das Profil zur Freigabe auf dem Host ist prinzipiell als Autostart gespeichert und kommt beim Hochfahren der VM stets mit hoch.
- Für jede weitere Verbindung zu anderem Server (z.B. anderer Rechner, andere VM im Netz) habe ich ein weiteres Profil gespeichert und lade es, sobald jener Server oben ist und dessen Freigabe zufällig brauche.
Die Profile lauten "<beliebig>.nbc", in ArcaOS unter \sys\apps\arcamap bzw. zusätzlich arcamap.ndc unter c:\os2 für Startup (analog bei eCS).
Es lohnt sich, diese Textdateien sofort nach dem Speichern zu kontrollieren, mehr als je 1 Zeile darin könnte zu besagtem Problem führen...
Nicht gerade mit dem "NET..."-Kommando, sondern eher mit "smbclient.exe", Syntax wahrscheinlich ziemlich wie in Linux. Der Arcamapper ist ja "nichts anderes" als eine elegante und narrensichere(re) Maskierung der Kommandos in \sys\apps\smbclnt. Und mit Autostart-Möglichkeit (sh.oben).Bestimmt gibt es die Möglichkeit einer einfachen "Batch-Datei",...
... wo man sich weiter einlesen könnte
Bitte nicht übelnehmen: Ganz ordentlich In der Arcamapper-'Hilfe'...
![Lachend :lol:](./images/smilies/icon_lol.gif)
Zuletzt geändert von LotharS am Do 24. Aug 2017, 21:06, insgesamt 1-mal geändert.
Habe die .nbc-Dateien geprüft, an diesen liegt es leider nicht ...LotharS hat geschrieben: War mir auch schonmal beim "Ausprobieren" passiert. Seitdem achte ich immer darauf, jede Verbindung pro Ressource nur 1mal herstellen zu lassen (notfalls wieder Unmount bzw. Detach) und prüfe die kleinen nbc-Dateien auf Plausibilität. Sehe ich daher nicht zwingend als "Software-Bug", wo _ich_ der Verursacher war.
Beispiel:
- Das Profil zur Freigabe auf dem Host ist prinzipiell als Autostart gespeichert und kommt beim Hochfahren der VM stets mit hoch.
- Für jede weitere Verbindung zu anderem Server (z.B. anderer Rechner, andere VM im Netz) habe ich ein weiteres Profil gespeichert und lade es, sobald jener Server oben ist und dessen Freigabe zufällig brauche.
Die Profile lauten "<beliebig>.nbc", in ArcaOS unter \sys\apps\arcamap bzw. zusätzlich arcamap.ndc unter c:\os2 für Startup (analog bei eCS).
Es lohnt sich, diese Textdateien sofort nach dem Speichern zu kontrollieren, mehr als je 1 Zeile darin könnte zu besagtem Problem führen...
Darauf muss man natürlich kommen>>... wo man sich weiter einlesen könnte
Bitte nicht übelnehmen: Ganz ordentlich In der Arcamapper-'Hilfe'...Sowie immer bei Netlabs.
![Lachend :lol:](./images/smilies/icon_lol.gif)
Was ich eigentlich nicht glaube: holt sich vielleicht der Samba-Client auch Einträge aus der smb.conf des Samba-Servers (den ich nicht installiert habe, weil eigentlich nur der Zugriff auf von außen "servierte" Resourcen angedacht war)?
Als "Gegenprobe wurde jetzt erstmal der Samba-Client deinstalliert und stattdessen IBM-Peerdienste installiert, damit Laufwerksverbindungen zu einem Win2000-Rechner (Win7 geht hier praktisch nicht) aufgebaut und Software gestartet. Ergebnis: alle Dateiöffnungen des Anwendungsprogramms in der OS/2-Sitzung verwenden (unter Win betrachtet) die gleiche SMB-Sitzung und die Offene-Datei-Anzahl steigt nur bei dieser SMB-Sitzung. Außerdem erfolgt der Dateizugriff mit dem alten IBM-Requester (wider Erwarten) um einiges zügiger als mit dem Samba-Client.
Damit wäre bewiesen, dass weder ArcaOS 5.0.1 noch die Virtualisierung das Problem ist!
Ungut nur, dass mit dem IBM-Requester der Zugriff nur gut auf Win2000-Resourcen funktioniert und der gewünschte Zugriff auf Win7-Resourcen nicht möglich ist, bzw. wegen der zahlreich nötigen Verbiegungen, die bei Win-Updates nicht standhalten, keine "handelbare" Alternative darstellt.
Es wäre also das beste, doch den Samba-Client unter ArcaOS nutzbar zu machen.
![Computerfreak :geek:](./images/smilies/icon_e_geek.gif)
- HerwigB
- Beiträge: 57
- Registriert: Mo 23. Dez 2013, 06:39
- Wohnort: Sankt Veit an der Glan
- Kontaktdaten:
Viele Fragen, ich werd mich bemühen, das alles nach Kräften zu beantworten.
- die Protokollstapel sind unter Win Client und Serverseitig dieselben (zumindest weitgehend).
- Unterschiede bestehen bei der Authentifizierung und da ist unser Client sowieso schwach, weil mehr als stinknormale User/Password Geschichten (in verschiedenen Sicherheitskonfigurationen) eh kaum geht. Das ist auch der Grund warum AN von Paul Smedley den neuen Plugin basierend auf Samba 4 basteln ließ. Mit dem Samba 4 basierend Plugin haben wir (derzeit) nichts zu tun.
- Die SMB2 Unterstützung in Samba 3.6 ist jedenfalls sehr durchwachsen - sie geht zwar, aber da gibts Ungereimtheiten. Ich würde SMB2 mit Samba 3.6 basierenden Komponenten nicht einsetzen (ist aber jedenfalls auch Samba-seitig und nicht nur port-seitig).
Man kann den Speed von SMB2 mit ansonsten identischer Installation durchaus testen und die Werte sind beeindruckend. Auf unserer Plattform ist der NIC Treiber aber oft der deutlich limitierendere Faktor.
Um sowas manuell über die startup.cmd hinzubekommen muss man ND.EXE aus den NetDrive Paket nehmen (und auch in der Hilfe dazu nachlesen). Die Syntax ist aber etwas..... ich sags freundlich: Mühsam. Dieses Interface wurde auch in ArcaMapper/EVFSGUI (die beiden sind 99,5% dasselbe) für das Autostart-Feature benutzt. Ich würde das nehmen.
Teilweise und nicht mit jeder Version. Das ist aber grundsätzlich nicht so tragisch, wie es im ersten Moment klingen mag und zwar weil:Bedeutet dies, daß die Verträglichkeit mit Windows 2000 Server, Windows Server 2003, 2003 R2, 2008, 2012 oder 2016 überhaupt nicht getestet wurde?
- die Protokollstapel sind unter Win Client und Serverseitig dieselben (zumindest weitgehend).
- Unterschiede bestehen bei der Authentifizierung und da ist unser Client sowieso schwach, weil mehr als stinknormale User/Password Geschichten (in verschiedenen Sicherheitskonfigurationen) eh kaum geht. Das ist auch der Grund warum AN von Paul Smedley den neuen Plugin basierend auf Samba 4 basteln ließ. Mit dem Samba 4 basierend Plugin haben wir (derzeit) nichts zu tun.
- Die SMB2 Unterstützung in Samba 3.6 ist jedenfalls sehr durchwachsen - sie geht zwar, aber da gibts Ungereimtheiten. Ich würde SMB2 mit Samba 3.6 basierenden Komponenten nicht einsetzen (ist aber jedenfalls auch Samba-seitig und nicht nur port-seitig).
Und das sind die blödesten (bzw am schwierigsten zu verfolgen): Wenn Probleme unter der Hand verschwinden ohne das man genau weiss was man gemacht hat. Und manchmal sitzen sie nicht unbedingt vor dem Rechner, aber das hilft nix, weil sowas findet man nie....Manche "Probleme" sitzen halt vor dem Bildschirm und erledigen sich manchmal wundersam.
Schwer zu sagen. SMB ist ein langsames Protokoll, SMB2 und SMB3 werden da einiges bringen.Wie ist denn die Performance des Samba-Clients bei anderen Umgebungen?
Man kann den Speed von SMB2 mit ansonsten identischer Installation durchaus testen und die Werte sind beeindruckend. Auf unserer Plattform ist der NIC Treiber aber oft der deutlich limitierendere Faktor.
Dazu gibt es zumindest Pläne bei AN.Kann man die Virtualisierung hier optimieren, damit nicht so hohe CPU-Last benötigt wird
Bitte das mit AN und Paul Smedley klären. Mit unserem letzten 2.x Client geht das definitiv.Bei einer Installation von ArcaOS 5.0.1 wurde der Samba-Client (NDFS32 Version 3.028 mit Netdrive-Plugin NDPSMB.DLL Version 3.00.x, ArcaMapper 2.6-beta) ebenso mit installiert.
[...]
Ist jemandem schon ein Zugriff auf Win2000- und Win7-Resourcen in dieser Konstellation gelungen? Es sollte doch möglich sein, unter ArcaOS auch auf Netzwerk-Laufwerke dieser Windows-Systeme zuzugreifen. Wie ist das zu schaffen?
Win Limitierung....dass der Win7-Host-Rechner, der die Laufwerks-Resourcen bereitstellt, keine erneuten Verbindungen mehr zulässt.
SMBCLIENT.EXE = komplett unabhängiger standalone FTP-artiger Samba Client, den wir nur benutzen um einige Dinge abzufragen. Mit dem geht das nicht....reihenweise eintragen und dann wiederholt und funktionssicher ablaufen lassen kann - ggf. Aufruf über STARTUP.CMD, geht dies etwa über SMBCLIENT.EXE? Wäre dankbar, wenn jemand einen kurzen Hinweis geben könnte, wo man sich weiter einlesen könnte.
Um sowas manuell über die startup.cmd hinzubekommen muss man ND.EXE aus den NetDrive Paket nehmen (und auch in der Hilfe dazu nachlesen). Die Syntax ist aber etwas..... ich sags freundlich: Mühsam. Dieses Interface wurde auch in ArcaMapper/EVFSGUI (die beiden sind 99,5% dasselbe) für das Autostart-Feature benutzt. Ich würde das nehmen.
Ja, natürlich. Insbesondere wenn das "Gegenüber" auch ein *nix-Samba ist, sind auch die Serverlogs von Nutzen. Aber die Logs sind wirklich das Wichtigste, die "quasselnde" Konsole und die Samba logs.Btw.: Ihr akzeptiert hoffentlich notfalls auch Tickets für "ungetestete" Server, vorausgesetzt man besitzt tatsächlich ArcaOS (statt nur drüber zu reden) und kann damit Client-Logs erzeugen?
Und wenn man nun noch einen Samba-Server als "Gegenstation" aufsetzt: kommt der akt. Stand des (bei AN mitgelieferten) Samba-Servers mit mehr als 20 eingehenden SMB-Sitzungen klar bzw. hat der ein (nach oben) konfigurierbares Limit?HerwigB hat geschrieben:Win Limitierung....dass der Win7-Host-Rechner, der die Laufwerks-Resourcen bereitstellt, keine erneuten Verbindungen mehr zulässt.
Zuletzt geändert von hneubert am So 27. Aug 2017, 09:28, insgesamt 1-mal geändert.
In diesem Diskussionsverlauf scheinen einige Unklarheiten zu herrschen, welche durch zusätzliche Erfindungen zu noch mehr Verwirrung führen. Grundsätzlich ist das "Samba" immer ein Server. Die Verwendung von "Samba-Client" im Titel oder von "Samba Client" ist daher schon sehr fragwürdig. Unter Linux bspw. würde man am ehesten darunter smbfs oder cifs-vfs verstehen. Unter Windows erübrigt sich diese Frage, da die enthaltene NTLM-Client-Unterstützung verwendet wird. Warum nun das Dienstprogramm smbclient des Servers plötzlich "Samba Client" sein soll, kann wohl niemand so richtig nachvollziehen? Eventuell weil es fast richtig klingt? Aber es ist nur ein sehr primitiver smb-Client und kein Samba-Client, daher leider überhaupt kein Ersatz für LM Client oder LAN Requester.hneubert hat geschrieben:Und wenn man nun noch einen Samba-Server als "Gegenstation" aufsetzt: kommt der akt. Stand des (bei AN mitgelieferten) Samba-Servers mit mehr als 20 eingehenden SMB-Sitzungen klar bzw. hat der ein (nach oben) konfigurierbares Limit?
Zu der eigentlichen Frage:
Der Eintrag von "max connections = 0" (ohne Begrenzung) kann natürlich auch auf jeden anderen gültigen Wert gesetzt werden.
Es ist zutreffend, dass in SMBCLIENT.EXE nicht das steckt, was hier gesucht wird.ak120 hat geschrieben:In diesem Diskussionsverlauf scheinen einige Unklarheiten zu herrschen, welche durch zusätzliche Erfindungen zu noch mehr Verwirrung führen.
....
Warum nun das Dienstprogramm smbclient des Servers plötzlich "Samba Client" sein soll, kann wohl niemand so richtig nachvollziehen?
Mein Problem, für das eine Lösung gesucht wird:
Unter ArcaOS bzw. OS/2, eCS laufende Programme sollen auf Resourcen zugreifen, die z.B. auf einem Win7-"Server" liegen.
Es hat sich gezeigt, dass der IBM-LAN-Requester (wohl im wesentlichen wegen der auf beiden Systemen unterschiedlichen Defaults und Möglichkeiten bezüglich Authentifizierung) sich hierzu nicht eignet. (NB: Wenn jemand doch eine gangbare Lösung hat: bitte konkret benennen, wie das definitiv funktioniert.) Läuft der "Server" unter Win2000, dann kann gut mit dem IBM-LAN-Requester gearbeitet werden, bei Win7 wohl nicht, zumindest nicht unproblematisch.
Also wurde auf "Client"-Seite der IBM-LAN-Requester deinstalliert und der "Samba-Client" installiert. Mit "Samba-Client" war in der Eingangsfragestellung ein Client bzw. Requester gemeint, der File-Zugriffe auf entfernt liegende Resourcen (von einem "Samba-Server" bereitgestellt) ermöglicht. Die dort angegebenen Komponenten NDFS32 und Netdrive-Plugin NDPSMB.DLL dürften ein Bestandteil davon sein. Trifft dies wohl nicht zu?
Gedankengang dabei war, dass mit diesem Client/Requester nicht nur auf von einem "echten Samba-Server" bereitgestellte Resourcen zugegriffen werden kann, sondern gleichermassen auf "normale Windows-Resourcen", d.h. Resourcen, die z.B. von einem Win7-Rechner bereitgestellt werden können (Freigabe/Share eines Laufwerks o.ä.). Dies klappt auch, nur werden (aus ungeklärtem Grund) bei vielen aufeinanderfolgenden Dateiöffnungen innerhalb des in der gleichen Sitzungen laufenden Programms (1 Prozess), untypischerweise (der LAN-Requester verwendet hierzu genau _eine_ SMB-Sitzung) mehrere SMB-Sitzungen "verbraucht", die den "servierenden Rechner" unter Win7 sehr schnell in sein Limit an maximal verwaltbaren SMB-Sitzungen für von ihm bereitgestellte Resourcen laufen lässt.
Hierzu war der erste Ansatzpunkt, ob es vielleicht der Client/Requester dahingehend umkonfiguriert werden kann, dass er pro Programm-Sitzung (die zahlreiche Dateioperationen im gleichen Prozess durchführt) auch nur eine SMB-Sitzung verwendet. Vielleicht könnte man das dem NetDrive-Plugin beibringen.
Als zweiter Ansatzpunkt käme noch die technisch weitaus aufwändigere Lösung in Betracht, auf der Win7-Maschine ergänzend einen "Samba-Server" aufzusetzen. Wenn sich also unter Win7 ein Samba-Server installieren und betreiben lässt, der nicht gleich bei 20 SMB-Sessions schlapp macht, wäre dies eine "Notlösung" zum Problem.
Damit scheint es dann zu gehen, wenn man "0" oder z.B. "300" oder eine anderen an der Notwendigkeit orientierten Wert einträgt.ak120 hat geschrieben:Zu der eigentlichen Frage:
Der Eintrag von "max connections = 0" (ohne Begrenzung) kann natürlich auch auf jeden anderen gültigen Wert gesetzt werden.
Es widerspricht zwar dem Konzept der möglichst weitgehenden Nutzung von ArcaOS, wenn hier auch noch ein "Samba-Server" nativ unter Win7 installiert und administriert werden muss, aber das könnte erstmal eine technische Lösung darstellen, solange der unter ArcaOS laufende "Samba-Client" nicht so optimiert werden kann, dass er nicht unnütz viele SMB-Sessions verwendet.
Zuletzt geändert von hneubert am Mo 28. Aug 2017, 00:20, insgesamt 2-mal geändert.
Wollte nun, nachdem der "Resourcen-Hunger" des OS/2-seitigen Client anscheinend nicht zu beseitigen ist, nun notgedrungen eine Samba-Server-Portierung für Win7/10 mal probieren, die man fallweise starten kann. Doch aus welcher Quelle kann so etwas heruntergeladen werden?
Kann es sein, dass das Problem gar nicht auf Seiten des ArcaOS-Client besteht, sondern eher mit Beschränkungen von Win zu tun hat?
Wenn ich's richtig verstehe, dann möchtest Du Deinen Win-Rechner nicht bloß zum gelegentlichen Austausch von Daten mit ArcaOS verwenden (wie ich es mache), sondern manchmal quasi als laufenden Fileserver?
Ich bin kein Win-Kenner (sonden darin höchstens ein dummy user
), aber vielleicht zeigt ja dieses Google-Finding in ähnliche Richtung??
Alternativ käme vermutlich (! nur geraten !) eine Win-Server-Edition in Betracht, oder halt lieber ein NAS ?
Oder aber meine Vermutung ist Unfug, dann mögen Dir hoffentlich hier vorbeischauende Allround-Profis punktgenau helfen
P.S.:
Das Kommando "smbclient" kannte ich von Linux her als einen "Samba-Client", und es taucht auch in ArcaOS auf. Aber wenn der ArcaMapper anders arbeitet und hier bestens funktioniert, auch gut.
Wenn ich's richtig verstehe, dann möchtest Du Deinen Win-Rechner nicht bloß zum gelegentlichen Austausch von Daten mit ArcaOS verwenden (wie ich es mache), sondern manchmal quasi als laufenden Fileserver?
Ich bin kein Win-Kenner (sonden darin höchstens ein dummy user
![Zwinkern ;)](./images/smilies/icon_e_wink.gif)
Alternativ käme vermutlich (! nur geraten !) eine Win-Server-Edition in Betracht, oder halt lieber ein NAS ?
Oder aber meine Vermutung ist Unfug, dann mögen Dir hoffentlich hier vorbeischauende Allround-Profis punktgenau helfen
![Lächeln :)](./images/smilies/icon_e_smile.gif)
P.S.:
Wieder hinzugelerntEs ist zutreffend, dass in SMBCLIENT.EXE nicht das steckt, was hier gesucht wird.
![Lächeln :)](./images/smilies/icon_e_smile.gif)
Zuletzt geändert von LotharS am Fr 15. Sep 2017, 13:42, insgesamt 1-mal geändert.
Richtig, es soll "richtig gearbeitet" werden können mit den Dateien, die auf dem Win-Rechner gelagert sind, inkl. der Notwendigkeit, dass auf Datenbankdateien mehrfach konkurrierend geöffnet werden und satzweise Sperren laufen. Früher war hierfür ein dedizierter File-Server üblich, doch heute ist der Funktionsumfang eigentlich in jedem "Workstation"-Betriebssysstem implementiert.LotharS hat geschrieben:Kann es sein, dass das Problem gar nicht auf Seiten des ArcaOS-Client besteht, sondern eher mit Beschränkungen von Win zu tun hat?
Wenn ich's richtig verstehe, dann möchtest Du Deinen Win-Rechner nicht bloß zum gelegentlichen Austausch von Daten mit ArcaOS verwenden (wie ich es mache), sondern manchmal quasi als laufenden Fileserver?
Es ist eine Eigenheit des Samba-Client auf OS/2-Seite, dass er "wild SMB-Sessions verbraucht". Damit läuft ein Win7 oder Win2000-Workstation-Betriebssystem bei üblichen Datenbank-Operationen sofort in das Limit der maximal möglichen SMB-Sessions und der Programmablauf erfolgt nicht mehr geordnet.
Wird auf der OS/2-Seite statt dem Samba-Client der IBMLAN-Requester verwendet, bildet Win2000 als "Server" sofort einen ordentlich laufenden Partner, der Dateisperren etc. verarbeitet. Auch kommt es zu keiner Verschwendung der SMB-Sessions. Win7 auf Serverseite kann allerdings wegen der Authentifizierungsthematik mit dem IBMLAN-Requester nicht sauber zu laufen gebracht werden bzw. wenn es mal läuft, ist die Sonderkonfiguration mit dem nächsten Win-Update wieder auf andere Sicherheitsrichtlinien, Registrierungsinhalte etc. umgestellt und das "Spiel" der manuellen Sonderkonfiguration beginnt von neuem. So kann man nicht arbeiten, wenn Systemaktualisierungen die Sonderkonfigurationen wieder über Bord werfen ...
Damit wäre es technisch wohl lösbar, wenngleich mir nicht bekannt ist, konkret welches (höhere) Limit an max. SMB-Sessions eine Win-Server-Edition überhaupt hat. Aber das SMB-Session-Limit ist bei der Win7-Workstation-Version nur wegen des verschwenderischen Umgangs mit SMB-Sessions seitens des Samba-Clients überhaupt ein echtes Limit. Ein Server-Betriebssystem anzuschaffen, nur weil ein Client das Problem hochschaukelt - das ist nun wirklich nicht einzusehen.LotharS hat geschrieben: Alternativ käme vermutlich (! nur geraten !) eine Win-Server-Edition in Betracht, oder halt lieber ein NAS ?
Man könnte jedenfalls auch Hunderte von Dateien, die über ein und die selbe Netzwerk-Freigabe bereitgestellt werden, in der gleichen (einen!) SMB-Session öffnen, anstatt viele SMB-Sessions zu verbrauchen. So machen das andere File-Requester auch.
Die Vermutung ist zwar richtig, aber "unser" OS/2-Weg ist auch mit mit den Allround-Profis zu schaffen, ohne auf Win-Seite noch "grosse Server-Lizenzen" aufzurüsten ... Da bin ich mir sicher!LotharS hat geschrieben: Oder aber meine Vermutung ist Unfug, dann mögen Dir hoffentlich hier vorbeischauende Allround-Profis punktgenau helfen![]()
Zuletzt geändert von hneubert am Sa 16. Sep 2017, 02:04, insgesamt 1-mal geändert.
Aufgrund des bisherigen Threadverlaufs liegt die Vermutung nahe, dass der aktuelle Samba-Client in der Anwendungspraxis eher für gelegentlichen, einfachen Dateiaustausch genutzt wird.
Hat denn faktisch kein Forums-Teilnehmer den Samba-Client unter ArcaOS im produktiven Einsatz an einem unter Win7/10 Pro laufenden "Server im Arbeitsstations-Netzwerk"?
Hat denn faktisch kein Forums-Teilnehmer den Samba-Client unter ArcaOS im produktiven Einsatz an einem unter Win7/10 Pro laufenden "Server im Arbeitsstations-Netzwerk"?
Zuletzt geändert von hneubert am Mi 27. Sep 2017, 10:56, insgesamt 1-mal geändert.