afp-Verbindungsversuch wird mit -5000 quittiert ?!

[stk]

Moin,

ich verzweifel gleich . Jeglicher Versuch zu meinem Tiger-Server eine afp-Filesharing-Verbindung aufzubauen, wird nach dem Login mit "Verbindung fehlgeschlagen -5000" quittiert. Der Dienst läuft, wirft keine Fehler aus. Auch der LDAP-Server zeigt keine Fehler an, die Authentifizierung wird als korrekt rückgemeldet.

Gleichen Fehler hatte ich letzte Woche auf einem Kundenserver, der jedoch nach einem Neustart behoben war. Auf meinem Server habe ich jetzt den 3. Neustart hinter mich gebracht, ohne das sich was änderte.

Der Fehler tritt unabhängig davon auf, mit welchem Benutzer ich versuche die Verbindung aufzubauen. Acuh mit Admin-Usern, bzw. Eigentümern der Shares schlägt die Verbindung fehl.

Brauche dringlich Hilfe!

[ergänzung]Eine SMB-Verbindung auf gleiche Vols funktioniert. Scheint also in der Tat ein AFP-only Problem zu sein - aber welches und wie krieg ich's gefixt?[/ergänzung]

[ergänzung2]Eine Gastverbindung via AFP gelingt auch - also ist's "nur" die AFP-Authentifizierung die in die Binsen geht.[/ergänzung]


Gruß Stefan

 

[slowfranklin]

Gerade auf 10.4.8 geupdated? Das macht zum Teil, bisher nicht nachvollziehbar, auch nach Vivisektion des Pakets und aller *flight-Scripts, interessante Dinge. U.a.:
- PasswordServer mag nicht starten wenn en0 und en1 verheiratet sind
- der Name des Kerberos Principals den afpd nutzt wird ihm hinterücks verstümmelt. Siehe

defaults read /Library/Preferences/com.apple.AppleFileServer | grep kerberosPrincipal

Sollte sein "afpserver/fqdn.mydoma.in@REALM" und nicht "afpserver".

-Ralph

 

[stk]

Hi

Hmm, der Kerberos Principal stimmt. Schade, das war's leider nicht .

Hab's eben gelöst, in dem ich die ACLs ausgeschaltet habe.

Gruß Stefan

 

[stk]

Moin,

auch nachdem die ACL abgeschaltet waren, verblieb auf einer AFP-Freigabe (die des Web-Roots) ein Fehler. Obwohl die Benutzerrechte sowohl im Arbeitsgruppenmanager für die AFP-Freigabe als auch im Serveradmin für den Webserver korrekt angelegt waren (www:www mit rwx und all rwx) wurden der Versuch neue Dateien auf das Filesharing-Volume zu legen mit "-50" quittiert.

Angeregt durch den Apple kBase-Artikel 304666 habe ich darauf hin versucht eventuelle Ungereimtheiten des Passwortservers zu korrigieren. Leider stellte sich die in o.g. Artikel aufgezeigte Anleitung als schwerst fehlerbehaftet heraus, so daß danach der PW-Server gar nicht mehr wollte. Falls jemand gleiche Probleme hat - hier die Auflösung:

Die Datei make-replica-file mit dem beschriebenen Inhalt erzeugen. Wichtig: die Codierung sollte nicht UTF-8 sein, da ansonsten im weiteren Fortgang fälschlicherweise ein Binary-Inhalt unterstellt wird und die nachfolgenden Aktionen fehlschlagen. Mit Windows ISO-Latin 1 hatte ich keine Probleme.

Die nachfolgende Erzeugung der Datei »authserverreplicas« mit Hilfe des Befehls

~/Desktop/make-replica-file > ~/Desktop/authserverreplicas

muß als root erfolgen! Ansonsten enthält die neue Datei »authserverreplicas« lediglich die entsprechende Fehlermeldung "Script must be run as root". Ergo: erstmal mit

su

zu root werden und dann o.g. Befehl ausführen.

Bei den dann beschriebenen Eingaben im Terminal stimmt die Reihenfolge nicht! Statt

$ sudo chown root:wheel /var/db/authserver/authserverreplicas  
$ sudo chmod 644 /var/db/authserver/authserverreplicas
$ sudo mv ~/Desktop/authserverreplicas/var/db/authserver

muß es heissen:

$ sudo mv ~/Desktop/authserverreplicas /var/db/authserver
$ sudo chown root:wheel /var/db/authserver/authserverreplicas  
$ sudo chmod 644 /var/db/authserver/authserverreplicas

Beachtet zudem, das in der korrekten Version in der ersten Zeile ein zusätzliches Leerzeichen erforderlich ist, damit der move-Befehl sowohl eine Quelle (die eben erzeugte authserverreplicas-Datei) als auch ein Ziel (in /var/db/authserver) hat.

Erst nach dieser Verschiebung macht es Sinn, die Rechte und den Eigentümer, die durch das Ersetzen der Datei korrupt werden, zu korrigieren.

Nach dem fälligen Neustart des Servers arbeitete der Passwort-Server wieder klaglos und auch die Zugriffe auf meine Filesharing-Vols funktionieren einwandfrei.

Eine Reaktivierung der ACLs habe ich noch nicht probiert, sehe aktuell auch keine Notwendigkeit mehr dafür.

Gruß Stefan

 

[stk]

.

 

[slowfranklin]

Du hast nicht zufällig noch die alte Datei /var/db/authserver/authserverreplicas und kannst die bitte mal posten?

Hofft

-Ralph

 

[Rastafari]

Wichtig: die Codierung sollte nicht UTF-8 sein, da ansonsten im weiteren Fortgang fälschlicherweise ein Binary-Inhalt unterstellt wird

Ich weiss ja nicht, welchen Texteditor du verwendest.
Aber bei der Wahl von "UTF-8, no BOM" oder vergleichbaren Optionen (UTF-8 ohne Tag / Bang! / Header...) sollte das nie passieren.

("Normales" UTF-8 besitzt tatsächlich einen 3 Byte langen Binärtag "0xEFBBBF" am Dateibeginn. Apples "TextEdit" benutzt sowas aber nicht. Nur diverse andere Editoren sind so zwanghaft standardkonform, wenn man sie nicht explizit vom Gegenteil überzeugt.)

 

[stk]

Moin,

Mein BBEdit macht das wohl so .
Nein, die alte authserverreplicas hab ich leider nicht mehr.

Gruß Stefan

 

[Rastafari]

Moin,Mein BBEdit macht das wohl so

BBEdit -> Preferences -> TextFiles: Saving -> Default Text Encoding