Problem mit netatalk: Timemachine Backup funktioniert nicht mehr

Midian

Well-Known Member
Seit einigen Wochen funktioniert das Backup via Timemachine von meinem Mavericks Macbook nicht mehr. Ich kann keinen bestimmten auslöser festmachen, sicher ist nur, dass auf der FreeBSD Box über Monate nichts verändert wurde. Mavericks habe ich natürlich regelmäßig aktualisiert.

Es gab allerdings einen abend, an dem ich das Backup gestartet habe, dieses aber aufgrund von Netzwerkproblemen abgebrochen habe (glaube die WLAN-Verbindung ist abgebrochen). Danach konnte ich es nicht mehr starten. Habe auf dem Macbook dann mal das Backup komplett deaktiviert, und beide Rechner neu gestartet. Auf dem Macbook wird mir nun das FreeBSD Volume angezeigt, wenn ich dieses aber fürs Backup auswählen will, kommt nach ein paar Sekunden warten die Fehlermeldung:

wlenw0.png


Jetzt bin ich etwas ratlos, ich kann in den Logs auf der FreeBSD Box auch nichts erkennen, während dem Verbindungsversuch. Lediglich nach dem Start des afd sehe ich in /var/log/messages:

Code:
Sep 13 10:38:26 epoch afpd[725]: AFP/TCP started, advertising 10.0.0.3:548 (2.2.4)
Sep 13 10:38:27 epoch afpd[725]: Failed to create client object: Daemon not running
Sep 13 10:38:27 epoch afpd[725]: av_zeroconf_unregister
Sep 13 10:38:27 epoch afpd[725]: av_zeroconf_unregister: avahi_threaded_poll_stop
Sep 13 10:38:27 epoch afpd[725]: av_zeroconf_unregister: avahi_client_free
Sep 13 10:38:27 epoch afpd[725]: av_zeroconf_unregister: avahi_threaded_poll_free

Auf die normalen Dateifreigaben kann ich allerdings immernoch problemlos zugreifen.

Kann mir da jemand unter die Arme greifen? Habe mittlerweile auch von FreeBSD 9.1 auf 9.3 aktualisiert, hat aber nichts gebracht :(
 
Ich würde mich auf das "Daemon not running" konzentrieren. Welcher Daemon könnte das sein und warum läuft er nicht?
 
Komme leider momentan nicht wirklich dazu, das nachzuverfolgen. Ich nutze aber avahi nicht, da ich bisher der Ansicht war, dass avahi zu schwergewichtig ist und zu viele Abhängigkeiten mit sich bringt. Nutze daher seit jeher mDNSResponder.

Habe auch bemerkt, dass o.g. Fehlermeldung wohl nur ein Folgefehler ist, da bereits mDNSResponder Fehler bringt, das hatte ich beim Erstellen des Posts übersehen. Ich habe jetzt erstmal auf 10.0 aktualisiert, bekomme jetzt folgende Fehler im Log:

Code:
Oct  1 21:58:29 epoch afpd[851]: AFP/TCP started, advertising 10.0.0.3:548 (2.2.5)
Oct  1 21:58:29 epoch mDNSResponder: mDNSResponder (Engineering Build) (Aug 20 2014 14:49:53) starting
Oct  1 21:58:29 epoch mDNSResponder:   8: Listening for incoming Unix Domain Socket client requests
Oct  1 21:58:29 epoch mDNSResponder: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
Oct  1 21:58:29 epoch mDNSResponderPosix: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801406D60 epoch.local. (Addr) that's already in the list
Oct  1 21:58:29 epoch mDNSResponderPosix: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801407180 3.0.0.10.in-addr.arpa. (PTR) that's already in the list
Oct  1 21:58:29 epoch mDNSResponder: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801406D60 epoch.local. (Addr) that's already in the list
Oct  1 21:58:29 epoch mDNSResponder: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801407180 3.0.0.10.in-addr.arpa. (PTR) that's already in the list
Oct  1 21:58:29 epoch mDNSResponderPosix: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801407D60 epoch.local. (Addr) that's already in the list
Oct  1 21:58:29 epoch mDNSResponderPosix: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801408180 3.0.0.10.in-addr.arpa. (PTR) that's already in the list
Oct  1 21:58:38 epoch ntpd[824]: time correction of 3751 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

Wenn ich den ersten Fehler google, finde ich: https://forums.freebsd.org/viewtopic.php?f=5&t=45440
Hier gibts aber leider auch keine schlussendliche Lösung.

Falls noch jemand eine Idee hat, wäre das toll. Werde aber vermutlich erst am Wochenende dazu kommen, das weiter zu verfolgen.


[edit] Ich will nochmal betonen, dass es mich ziemlich fertig macht, dass auf der FreeBSD Box für Monate *nichts* angefasst wurde. Ich habe keine Pakete aktualisiert und keine Konfiguration geändert. Dennoch ging das Backup von einem Tag auf den anderen nicht mehr. Falls es tatsächlich an IPv6 liegt, könnte es ja aber sein, dass sich z.b. Mac OS diesbezüglich anders verhält, da ich hier regelmäßig Updates installiere ... ?
 
Bevor wir intensiv in die Tiefe gehen und am Schluß der Fehler ganz banal ist: Stelle mal deine Uhr richtig ein:
Oct 1 21:58:38 epoch ntpd[824]: time correction of 3751 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
Es gibt viele Dienste, die eine einigermaßen passende Uhrzeit brauchen.
 
Bevor wir intensiv in die Tiefe gehen und am Schluß der Fehler ganz banal ist: Stelle mal deine Uhr richtig ein:
Es gibt viele Dienste, die eine einigermaßen passende Uhrzeit brauchen.

Oja...es hat mich mal zwei Tage gekostet, bis IPSec lief. Und es lag einfach an der Uhrzeit. :D
 
Hat leider nicht geholfen:

Code:
Oct 17 17:28:18 epoch ntpd[801]: ntpd 4.2.4p5-a (1)
Oct 17 17:28:18 epoch afpd[829]: AFP/TCP started, advertising 10.0.0.3:548 (2.2.5)
Oct 17 17:28:18 epoch mDNSResponder: mDNSResponder (Engineering Build) (Aug 20 2014 14:49:53) starting
Oct 17 17:28:18 epoch mDNSResponder:   8: Listening for incoming Unix Domain Socket client requests
Oct 17 17:28:18 epoch mDNSResponder: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
Oct 17 17:28:18 epoch mDNSResponderPosix: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801406D60 epoch.local. (Addr) that's already in the list
Oct 17 17:28:18 epoch mDNSResponderPosix: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801407180 3.0.0.10.in-addr.arpa. (PTR) that's already in the list
Oct 17 17:28:18 epoch mDNSResponder: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801406D60 epoch.local. (Addr) that's already in the list
Oct 17 17:28:18 epoch mDNSResponder: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801407180 3.0.0.10.in-addr.arpa. (PTR) that's already in the list
Oct 17 17:28:18 epoch mDNSResponderPosix: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801407D60 epoch.local. (Addr) that's already in the list
Oct 17 17:28:18 epoch mDNSResponderPosix: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801408180 3.0.0.10.in-addr.arpa. (PTR) that's already in the list
Oct 17 17:28:24 epoch ntpd[802]: time reset -0.853101 s
 
Laut man page started afpd irgendwelche virtuellen file server.

Meine Vermutung: Du kannst afpd prinzipell kontaktieren, weil er ja gestartet ist. Aber machen kannst du nix, weil er mindestens einen (und wohl den relevanten) server nicht starten kann. Und eben dies scheint auch die Zeile "Sep 13 10:38:27 epoch afpd[725]: Failed to create client object: Daemon not running" im log zu sagen.

Ich vermute, eventuell hier anwesende Profis in Sachen apple Zeug (zu denen ich nicht gehöre) könnten dir besser helfen, wenn du deine afpd.conf postest.

Ansonsten verrät die man page noch, dass du afpd mit --enable-debug1 compilieren kannst, um ein wohl hilfreiches afp command trace zu bekommen.
 
Bitte nur den letzten Logausschnitt betrachten. Ich habe mittlerweile auf 10.0 aktualisiert, seitdem kommen die im Eingangspost genannten Fehler nicht mehr. Ich denke es ist ein Problem des mDNSReponders.

Code:
Oct 17 17:28:18 epoch mDNSResponder: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
Oct 17 17:28:18 epoch mDNSResponderPosix: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 0000000801406D60 epoch.local. (Addr) that's already in the list
 
Also ich hatte mit der Auswahl mDNS auch zwischenzeitlich meine Probleme.
Hab daher auf avahi geschwenkt - seit dem läufts.

rc.conf-Reihenfolge, die bei mir problemlos läuft:
Code:
dbus_enable="YES"
avahi_daemon_enable="YES"
netatalk_enable="YES"

Gruß
Markus
 
Zurück
Oben