Hallo,

ich teste gerade Leopard und bin auf folgendes Problem gestoßen:
Wir betreiben im Haus einige Windows-2000-Server mit aktiviertem AFP 2.0. Das funktioniert mit den üblichen Einschränkungen (nur 23 Zeichen, keine Sonderzeichen). Leider hat Leopard mit dieser Konstellation Schwierigkeiten: ich erhalte in der Regel die Meldung "Verbindung fehlgeschlagen" und ich soll prüfen, ob der Server läuft und erreichbar ist. Ist er natürlich. Manchmal klappt es aber auch, selten, aber immer wieder mal dazwischen.

Hat zu dem Problem schon jemand was gehört?
Danke
Peter

Kleiner Nachtrag:

Die Windows-Server sind von Tiger aus sowohl über SMB wie auch über AFP erreichbar, wobei die Windows-Shares in Ordnern gezeigt werden, die die Namen der Arbeitsgruppen tragen. Uner Leopard wird das AFP-Share der Windows-Server gar nicht mehr gezeigt, ich sehe nur noch Windows-Icons. Das aber auch nur, wenn ich die Firewall komplett deaktiviere; mit aktivierter Firewall sehe ich die Windows-Rechner überhaupt nicht mehr. Das ist alles noch ziemlich ominös. Wenn mir jemand Literatur dazu hätte, wöre ich dankbar.

Grüße
Peter

Hallo Peter!
Wir haben einen NT 2003 Server bei uns in der Agentur - sonst nur Macs.
Einen der Macs habe ich zur Probe mit Leopard bestückt und schon komme ich mit diesem Rechner auch nicht mehr per afp auf unseren Server.
In der neuen Finder-Leiste links meldet sich der Server zwar unter Freigaben, wenn ich dort zugreife, bekomme ich ihn aber nur über SMB und das will ich nicht.
Per Apfel+K spreche ich den Server direkt per AppleTalk an (afp://...) aber bekomme nur "Verbindung fehlgeschlagen" - egal ob Login als Gast oder Benutzer und Passwort.

Habe dazu ausgiebig das Netz durchgesiebt und bin auf folgende Beiträge in den Apple Discussions gestossen:

http://discussions.apple.com/thread.jspa?threadID=1194596&tstart=15



Von dort verzweigt sich ein Link auf diese Seite:

http://blog.wearesakuzaku.com/94-making-netatalk-work-on-debian-with-leopard/



und dann weiter hierhin:

http://www.blackmac.de/archives/58-Make-Netatalk-talk-to-Leopard-Mac-OS-X-10.5.html


Hier ist zwar immer von Leopard und Linux die Rede aber es scheint das gleiche Problem wie unseres zu sein.
Soweit ich das richtig verstehe, konnte Tiger cleartext UAM (Passwörter) senden und genau das ist mit Leopard nicht mehr möglich.
Leopard erlaubt keine cleartext AFP Passwörter.
"But Leopard apparently no longer allows cleartext AFP passwords at all, because I could no longer connect to any netatalk shares with just the cleartext UAM."

Deshalb meldet der Server wohl ein falschen Login Namen oder Passwort.

Das ist mein momentaner Wissensstand - weiter bin ich noch nicht gekommen.
Kannst Du Dich hier mit einbringen oder sind das für Dich (wie auch für mich) böhmische Dörfer?

Viele Grüße
Axel

Hallo Axel,

Antwort auf [ Oxxle ]

Soweit ich das richtig verstehe, konnte Tiger cleartext UAM (Passwörter) senden und genau das ist mit Leopard nicht mehr möglich.
Leopard erlaubt keine cleartext AFP Passwörter.
"But Leopard apparently no longer allows cleartext AFP passwords at all, because I could no longer connect to any netatalk shares with just the cleartext UAM."

Ich habe gestern noch ziemlich lange gesucht, aber dazu nichts gefunden ... Danke, das ist mit Sicherheit die "Lösung" - soweit man von einer Lösung sprechen kann. Ich kann mich erinnern, dass wir bei Tiger umschalten mussten auf unverschlüsseltes Login, was bei Leopard offenbar nicht mehr geht.

Ich habe noch eine Lösung gefunden zu meinem anderen Problem, den nicht auftauchenden Windows-Shares.
1. Die Shares tauchen nur auf, wenn man die Firewall ausmacht. Kurios, aber vermutlich kein Bug sondern ein Feature. Da Apple die normale UNIX-Firewall verwendet, wird es wohl bald Patches dafür geben.

2. Damit die Shares zuverlässig auftauchen und auch bleiben, muss in den Systemeinstellungen Netzwerk eine Arbeitsgruppe definiert werden, was aber bei von Tiger übernommenen Umgebungen nicht funktioniert. (Das ist ein Bug). Bei mir hat es ausgereicht, eine neue Umgebung anzulegen und dort die Arbeitsgruppe einzustellen. Seitdem geht meine normale Umgebung auch. Auch kurios.

Das Problem mit der Passwort-Verschlüsselung ist sehr ärgerlich; das wird eine ganze Menge kleiner Vorstufenbetriebe ganz empfindlich treffen, wenn es nicht gelingt, das Problem zu lösen. Viele arbeiten mit Windows-Servern oder NetaTalk auf Linux. Klar, eine professionelle Lösung wäre ein ordentlicher AFP-Server, da gibt es ja einige, aber ich glaube kaum, dass ich das hier im Haus durchbringen kann. Da wird es eher heissen: kein Update auf Leopard bis das funktioniert.

Ich werde erstmal weiter recherchieren und mich nochmals melden.

Gruß
Peter

Hallo Peter,

sollte es nicht reichen in der com.apple.AppleShareClient.plist wieder "afp_cleartext_allow" zu setzen und "afp_cleartext_warn" auf "Yes" zu stellen?

Hallo Thomas,

Antwort auf [ Thomas Richard ]

Hallo Peter,

sollte es nicht reichen in der com.apple.AppleShareClient.plist wieder "afp_cleartext_allow" zu setzen und "afp_cleartext_warn" auf "Yes" zu stellen?

Danke für den Hinweis. Ich habe dazu recherchiert und einiges dazu gefunden; etlichen hat das geholfen mit NetaTalk. Leider scheint es bei meinem Problem mit den Windows-Freigaben nicht zu funktionieren. Kann gut sein, dass es hier mehrere Probleme gibt, die Klartext-Passwörter und ein veraltetes AFP. Vielleicht mache ich auch etwas falsch. Die com.apple.AppleShareClient.plist gibt es zweimal, einmal in /Library/Preferences und einmal in ~/Library/Preferences. Ich habe es im User-Verzeichnis umgestellt.

Seltsam auch, dass dieser Befehl im Terminal:

Code

defaults read com.apple.AppleShareClientCore 

eine Fehlermeldung ergibt:

Code

com.apple.AppleShareClientCore does not exist 

Das wurde offenbar anders organisiert in Leopard.

Gruß
Peter

Antwort auf [ Linzenkirchner ]

Die com.apple.AppleShareClient.plist gibt es zweimal, einmal in /Library/Preferences und einmal in ~/Library/Preferences. Ich habe es im User-Verzeichnis umgestellt.

Da hätt ich jetzt mal spontan genau die andere geändert, Schliesslich entsteht das Problem ja quasi erst in dem Schritt wo jemand anonymes zu einem bekannten Benutzer wird. Aber das jetzt nur mal so aus 'gesundem Menschenverstand' fabuliert.

Antwort auf [ Linzenkirchner ]

Seltsam auch, dass dieser Befehl im Terminal:

Code

defaults read com.apple.AppleShareClientCore 

eine Fehlermeldung ergibt:

Code

com.apple.AppleShareClientCore does not exist 

Da mein OS X 10.4.10 das da ausgibt:

Code

defaults read com.apple.AppleShareClientCore 
2007-10-31 16:07:08.331 defaults[1084]  
Domain com.apple.AppleShareClientCore does not exist 

Würde ich mal vermuten, dass du da irgendwie komplett auf'm falschen Dampfer bist. Was soll das sein?

Hallo Thomas,

Antwort auf [ Thomas Richard ]

Da hätt ich jetzt mal spontan genau die andere geändert, Schliesslich entsteht das Problem ja quasi erst in dem Schritt wo jemand anonymes zu einem bekannten Benutzer wird. Aber das jetzt nur mal so aus 'gesundem Menschenverstand' fabuliert.

Habe ich mittlerweile auch getestet, leider mit dem gleichen Ergebnis. In der Benutzer-Datei waren die beiden Optionen anfangs schon drin, mit false allerdings; deshalb habe ich sie zuerst hier umgestellt.

Antwort auf [ Linzenkirchner ]

Würde ich mal vermuten, dass du da irgendwie komplett auf'm falschen Dampfer bist. Was soll das sein?

He he, kann schon sein. Eigentlich sollte eine Liste der aktuellen Grundeinstellungen kommen, siehe http://discussions.apple.com/...5606066&tstart=0

Na ja, auskennen tue ich mich hier wirklich nicht besonders und deshalb suche ich mir Informationen zusammen, wie ein Huhn Körner :-)

Nachtrag:
Hier ist auch ein entsprechender Hinweis für Netatalk: http://is-here.com/. Aber seine Codezeile

Code

defaults write -g com.apple.AppleShareClientCore -dict-add afp_cleartext_allow -bool true 

wirft zwar keinen Error, bewirkt aber auch nichts. Zumindest ändert sie die plist-Dateien nicht.

Gruß
Peter

Hier mit den richten Parametern:

defaults write com.apple.AppleShareClient afp_cleartext_allow -bool true

Und 10.5 verbindet wieder mit Windows

SuPerNova

Wenn du auf dem Win 2000/2003 den AFP Server Mac Server IP 9 installiert, läuft alles wieder prima. Zusätzlich sind die bekannten Einschränkungen von Windows AFP 2.0 hinfällig.