foren24.at

Hi Group,

wir haben gestern einen Windows Server ausgetauscht (W2K3SP2) und hatte
heute einige Probleme einen SMB_Mount auf eine Serverfreigabe einzurichten.
Von insgesamt ca. 20 Macs konnten sich ca. 5 nicht mit der Freigabe
verbinden. Mac OS der betroffenen Maschinen 10.5.8 und 10.4.11.

Meine letzte verzweifelte Tat war dann anstatt die IP-Adresse des SMB
Servers in der Mount URL, den NetBIOSNamen des Servers zu verwenden und
dann hatte es plötzlich funktioniert. Normalerweise hatte ich bislang noch
*nie* Probleme mit einer IP, eher noch mit einem Hostnamen. Hat jemand eine
Idee, woran das liegen könnte?

Der Windows Server ist Mitglied einer Arbeitsgruppe und die Fehlermeldung
auf Mac OS war in etwa: Fehler beim Verbinden, weil einige Daten im
[Share_Name] nicht gelesen werden können. Fehler -36.

Thx & Bye Tom
--
"Ich weiß nicht, was der französische Staatspräsident Mitterand denkt, aber
ich denke dasselbe." (Helmut Kohl)

Thomas Wildgruber wrote:

Hi Group,

wir haben gestern einen Windows Server ausgetauscht (W2K3SP2) und hatte
heute einige Probleme einen SMB_Mount auf eine Serverfreigabe einzurichten.
Von insgesamt ca. 20 Macs konnten sich ca. 5 nicht mit der Freigabe
verbinden. Mac OS der betroffenen Maschinen 10.5.8 und 10.4.11.

Meine letzte verzweifelte Tat war dann anstatt die IP-Adresse des SMB
Servers in der Mount URL, den NetBIOSNamen des Servers zu verwenden und
dann hatte es plötzlich funktioniert. Normalerweise hatte ich bislang noch
*nie* Probleme mit einer IP, eher noch mit einem Hostnamen. Hat jemand eine
Idee, woran das liegen könnte?

Der Windows Server ist Mitglied einer Arbeitsgruppe und die Fehlermeldung
auf Mac OS war in etwa: Fehler beim Verbinden, weil einige Daten im
[Share_Name] nicht gelesen werden können. Fehler -36.

Thx & Bye Tom

Solche Probleme haben wir mit Windows 2008er Servern. Geht problemlos
mit 10.6, bei 10.5 am besten via smb:\\server:139\freigabe und mit 10.4
gar nicht. Liegt wohl an der SMB/CIFS-Version, ab Windows 2008 ist es
Version 2, vorher 1.x. Geht verschiedenen Drucker/Scannerkombis von
Xerox oder Ricoh auch so.
--
Dirk Kring

On Thu, 1 Jul 2010 17:11:25 +0200, Dirk Kring wrote:

Solche Probleme haben wir mit Windows 2008er Servern. Geht problemlos
mit 10.6, bei 10.5 am besten via smb:\\server:139\freigabe und mit 10.4
gar nicht. Liegt wohl an der SMB/CIFS-Version, ab Windows 2008 ist es
Version 2, vorher 1.x. Geht verschiedenen Drucker/Scannerkombis von
Xerox oder Ricoh auch so.

Mit anderen Worten, du schreibst einfach noch den Port hinter den
Servernamen? BTW: Das du die URL mit Backslash geschrieben hast, war ein
Versehen oder?

Bye Tom
--
"Jeder muss im job permanently seine intangible assets mit high risk neu
relaunchen und seine skills so posten, dass die benefits alle ratings
sprengen, damit der cashflow stimmt. Wichtig ist corporate identity, die
mit perfect customizing und eye catchern jedes Jahr geupgedatet wird!"(H.K)

On Thu, 1 Jul 2010 17:11:25 +0200, Dirk Kring wrote:

Solche Probleme haben wir mit Windows 2008er Servern. Geht problemlos
mit 10.6, bei 10.5 am besten via smb:\\server:139\freigabe und mit 10.4
gar nicht. Liegt wohl an der SMB/CIFS-Version, ab Windows 2008 ist es
Version 2, vorher 1.x. Geht verschiedenen Drucker/Scannerkombis von
Xerox oder Ricoh auch so.

Okay, ich hab das jetzt mal ausprobiert und bei uns hat es nichts gebracht
den Port mit anzugeben. Ich habe jetzt mal mit tcpdump den Traffic
mitgeschnitten, einmal wo es funktioniert und einmal wo es nicht
funktioniert.

Bei der funktionierenden Verbindung kommt zweimal über NetBIOS Session
Service (NBNS) ein Broadcast von der Mac OS Workstation mit einem "Name
query NB 192.168.111.191<20>" (was die Server IP wäre) gefolgt von einem
normalen TCP Handshake, danach gehts nur noch über SMB weiter.

Bei einer fehlgeschlagenen Verbindung habe ich den NBNS Broadcast
ebenfalls, jedoch folgt vom Mac ein weiteres NBNS Packet direkt an den
Zielhost (den Windows Server) mit einem "Name query NBSTAT <00><00><00>
usw". Darauf kommt es ebenfalls zum TCP Handshake, was allerdings vom
Server mit einem NBNS Packet "negativ session response, not listening on
called name" quittiert wird. Darauf wird die Verbindung ordendlich abgebaut
und die zwei versuchen es nochmal - vergebens.

Fazit: Im Gegensatz zu der funktionierenden Verbindung, wo die NetBIOS
Geschichte sich nur auf zwei Broadcasts beschränkt, bleibt die
fehlgeschlagene Verbindung in der NBNS Kommunikation stecken. Und im
Gegensatz zu der funktionierenden Verbindung, vo es bei den NBNS Broadcasts
bleibt, wird bei der fehlgeschlagenen Verbindung vom Mac eine direkte
Verbindung über NBNS zum Zielhost aufgebaut, ab da geht dann nichts mehr.
Auch erwähnenswert ist, dass bei der Verbindung gar kein Hostnamen
angegeben wird, der eine Namensauflösung erforderlich machen würde.

Für meinen laienhaften Sachverstand schaut es so aus, als ob der Ursprung
für das Chaos der Mac ist, jedoch haben wir an den Workstations nichts
verändert, sondern nur den Windows Server ausgetauscht, wobei dieser sogar
noch das selbe Betriebssystem (2003) hat, lediglich der Patchlevel ist auf
der jetztigen Maschinen aktueller.

Kann da jemand erklärend dazu stossen?

Thx & Bye Tom
--
"One good Whiskey a day, keeps the doctor away"

Thomas Wildgruber wrote:

On Thu, 1 Jul 2010 17:11:25 +0200, Dirk Kring wrote:

Solche Probleme haben wir mit Windows 2008er Servern. Geht problemlos
mit 10.6, bei 10.5 am besten via smb:\\server:139\freigabe und mit 10.4
gar nicht. Liegt wohl an der SMB/CIFS-Version, ab Windows 2008 ist es
Version 2, vorher 1.x. Geht verschiedenen Drucker/Scannerkombis von
Xerox oder Ricoh auch so.

Mit anderen Worten, du schreibst einfach noch den Port hinter den
Servernamen? BTW: Das du die URL mit Backslash geschrieben hast, war ein
Versehen oder?

Bye Tom

Ja.

Wenn du den Dienst Dateiserver für Macintosh verwenden würdest, hätte
ich noch den Tipp gehabt, im Sharing Bereich des Servers noch mit den
Authentifiziereungsmethoden rumzuspielen, wie Ms und Apple Cleartext und
so. Aber ich glaube, das gilt nicht für smb.

Hast du schon mal nach "Server message block signing" geschaut?



speziell Abschnitt

Digitally sign communications (always)

in der registry abgebildet unter:

Windows Server 2003 and Windows XP policy is named "Microsoft network
server: Digitally sign communications (always)"

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parame
ters

Value Name: RequireSecuritySignature
Data Type: REG_DWORD
Data: 0 (disable), 1 (enable)

Note The default value in Windows Server 2003 domain controllers and
Windows 2000 domain controllers is 1 (required). The default value in
Windows NT 4.0 domain controllers is 0 (not required).

an der Stelle mal testweise 0 eintragen.
--
Dirk Kring

Hi,

On Fri, 2 Jul 2010 10:25:32 +0200, Dirk Kring wrote:

Hast du schon mal nach "Server message block signing" geschaut?

Probleme mit SMB-Signing sind mir eigentlich nur in Verbindung mit
Domänencontrollern bekannt, hier haben wir nicht mal eine Domäne. Die
(Default) Einstellungen auf dem Server, betreffend dem SMB-Signing wären:

\lanmanserver\enablesecuritysignature = 0
\lanmanserver\requiresecuritysignature = 0
\lanmanworkstation\enablesecuritysignature = 1
\lanmanworkstation\requiresecuritysignature = 0

Demnach ist SMB-Signing im Prinzip nicht aktiviert. Ich vermute den Fehler
nicht an diesen Settings.

Bye Tom
--
"Manches Gewissen ist nur rein, weil es nie benutzt wurde" (Robert Lembke)

Thomas Wildgruber wrote:

Hallo.

Für meinen laienhaften Sachverstand schaut es so aus, als ob der Ursprung
für das Chaos der Mac ist, jedoch haben wir an den Workstations nichts
verändert, sondern nur den Windows Server ausgetauscht, wobei dieser sogar
noch das selbe Betriebssystem (2003) hat, lediglich der Patchlevel ist auf
der jetztigen Maschinen aktueller.

Kann da jemand erklärend dazu stossen?

Leider nicht. Vielleicht mal in einer Windows Server- oder Samba-
Gruppe/Mailingliste etc. fragen.

Ganz allgemein nur der Hinweis: Mac Clients und SMB als Netzwerk-
protokoll ist immer die schlechteste aller Lösungen. Es gibt viele
andere Lösungen, die alle besser sind, angefangen von DAVE über
Extreme-Z IP bis hin zu AFP.
--
Beste Gruesse, Hannes Gnad h.gnad@apfelwerk.de
Apple Distinguished Professional http://www.apfelwerk.de
Apple Certified Technical Coordinator 10.6 http://training.apple.com
Der Apfelwerk-Blog, live aus dem Alltag --- http://www.apfelwerk.de/blog