Freigabe-2 Freigaben werden hochgezählt

joergSt

joergSt

Mitglied
Thread Starter
Dabei seit
08.03.2008
Beiträge
45
Reaktionspunkte
5
Ein Problem das ich nur ab und an mal habe, heute nervt es mich aber so, das ich Nachfrage. Der Auslöser dafür ist mir nicht ganz klar, weil es nicht immer auftritt.
Die Freigaben werden hochgezählt, so das aus meinem "/NAS-Datenspeicher/" dann "/NAS-Datenspeicher-2/" oder "/NAS-Datenspeicher-3/" wird und Chronosync einen Fehler wirft, weil beim Backup die orginale Freigabe "/NAS-Datenspeicher/" nicht gefunden werden kann.

Hab heute morgen den Mac zu Arbeitsbeginn neu gestartet und dann wars es wieder bei "/NAS-Datenspeicher-2/". Wenn ich mich händisch mit den Freigaben verbinde sehe ich das es hochgezählt wurde, Verbinden geht natürlich. Wenn ich ich danach auch das NAS neustarte sortiert sich das wieder und alles ist gut. Liegt auch nicht am NAS, weil das hatte ich auch schon mit normalen externen Festplatten.

Das ganze unter OS 13.2.1, hatte ich bei älteren Systemen aber auch ab und an. Ich wechsle schon mal den Arbeitsplatz und damit auch die Netzwerkumgebung, im homeoffice steht die auf automatisch, im Büro gibts ein eigenes Setting für Gateway und DHCP.

Wo liegen diese Freigabenamen und wieso werden die alten nicht gelöscht bzw. nicht weiterverwendet? kann man die via terminal/script automatisert loswerden/neu setzen? unter /volumes seh ich ja nur immer den aktuellen

vG
jst
 
Das Problem liegt weniger am Mac sondern am NAS welches, warum auch immer, seinen Namen ändert weil es wohl denkt dieser sei schon vergeben.
Hat das NAS eine feste IP? Hat es nur 1 Zugang zum Netz?
 
  • Gefällt mir
Reaktionen: dg2rbf und joergSt
Das Phänomen kenn' ich und ist hier auch schon (selten) aufgetreten. Ich vermute anders als @AgentMax , dass es in Zusammenhang steht mit GUI-Meldungen wie "nicht korrekt ausgeworfen".
D.h. beim Wechsel der Netzwerkumgebung hatte irgendetwas noch Dateien auf dem Volume geöffnet und wenn der Mac versucht, die Verbindung in der neuen Umgebung wieder aufzubauen, ist der ursprüngliche Name noch vergeben.

Im Terminal siehst du deine Verbindungen (und evtl. die halb-geschlossenen) mit
Code:
df -m
 
  • Gefällt mir
Reaktionen: dg2rbf und joergSt
@AgentMax ja feste IP, ja nur einen Netzwerk-Zugang. Das mit dem NAS glaube ich noch nicht so ganz, weil ein paar mal hatte ich das gleiche Problem mit einer externen USB Platte, die wird dann als /Volumes/festplatte-2/ gemountet..

@MrChad: Fehlermeldungen hatte ich keine, Rechner wird korrekt runtergefahren und in neuer Umgebung neu gestartet. Nur im Homeoffice wird auf das NAS zugegriffen, im Büro geht das Backup auf unsere Fileserver. Werd das mit df mal im Auge behalten. Danke.

Da das nicht permant passiert/regelmässig, macht es die Ursachensuche schwierig. Timemachine hat heute morgen ohne Problem auf das NAS zugegriffen, das geht laut Protokoll via IP4, Chronosync und CarbonCopyCloner greifen via IP6 zu und haben Fehler geliefert. Liegts am SMB? Oder am DHCP vom Rechner? (erklärt /festplatte-2/ aber noch nicht..). Werden die Freigabe Namen ge-chached und klemmts da?
 
Es kann am Router und dessen SMB Namens Caching liegen.
Ähnlich wie der Mac Name auch hochgezählt wird.
Probier doch mal über die IP statt Namen.

Oder du trennst die Verbindung nicht richtig und MacOS denkt die ist noch da.
 
  • Gefällt mir
Reaktionen: dg2rbf und joergSt
Werden die Freigabe Namen ge-chached und klemmts da?
Wenn deine Netzwerkverbindungen beim Reboot von alleine zurückkommen, dann ist mglw. einer der diversen Automount-Tricks am Werke. Da wissen wir hier nichts drüber und das kann durchaus eine Rolle spielen.
 
  • Gefällt mir
Reaktionen: dg2rbf und joergSt
@oneOeight: danke.
Der Zugriff an sich ist ja nicht das Problem, geht ja im Finder immer reibunglos, sondern das sich die Backuptools beschweren, weil sie die Freigabenamen bei Ausführung des Zeitplans nicht mehr finden können. Die Volumen werden von CCC und Chronosysnc normalerweise sauber gemounted, backup durchgeführt, unmonted. Fertig. Und den Rechner fahre ich abends immer komplett runter, dann sollte doch alles sauber getrennt sein.
Ich wüsste gerade nicht wie ich da via IP zugreife, in beiden Apps kann ich nur die Freigaben auswählen. Könnte natürlich beim Rechnerstart alle Volumen mounten und das nicht den beiden Apps überlassen, hiesse aber ich hätte permant alles gemounted.. mhhh.. kniffelig
 
Der Grund liegt meist am avahi daemon, der auf den NAS läuft.

Ein bug report für avahi ist seit langen Jahren vorhanden.

Teilweise workarounds sind, den DHCP-Lease des Routers deutlich höher zu setzen (x Tage) oder den avahi daemon nach Aufwachen aus dem Ruhezustand des NAS neu zu starten. Letzteres hilft immer.
 
  • Gefällt mir
Reaktionen: joergSt
Kannst du im Router nicht die Namen und IPs auch bei DHCP festlegen?
Vielleicht löst das schon das Problem.
 
  • Gefällt mir
Reaktionen: joergSt
Gelöscht..
 
Kannst du im Router nicht die Namen und IPs auch bei DHCP festlegen?
Vielleicht löst das schon das Problem.

eilweise workarounds sind, den DHCP-Lease des Routers deutlich höher zu setzen (x Tage)

Das NAS macht kein DHCP, sondern hat eine feste IP (hatte ich ja auch schon geschrieben), wüsste jetzt auch nicht wie ich mit der Fritzbox die Freigaben auf dem NAS steuern könnte, da müsste die Fritzbox Zugriff auf die Freigabesteuerung haben :unsure:

Dem Hinweis auf den avahi daemon geh ich mal nach, danke!
 
wüsste jetzt auch nicht wie ich mit der Fritzbox die Freigaben auf dem NAS steuern könnte, da müsste die Fritzbox Zugriff auf die Freigabesteuerung haben
Da kannst du höchstens Namensvergabe steuern im lokalen DNS der Fritz.
 
  • Gefällt mir
Reaktionen: dg2rbf
Das NAS macht kein DHCP, sondern hat eine feste IP (hatte ich ja auch schon geschrieben),

und am Mac?

Es wird aber an avahi liegen.

https://github.com/lathiat/avahi/issues/117 besonders das Posting vom 20.05.2017.

Das ist auch der Grund, warum bei manchen Tools, wie z.B. dem bonjour-sleep-proxy-client, die mit avahi arbeiten, bei einem Aufwachen nach Sleep, erst mal der avahi-daemon neu gestartet wird. So wird eben das hochzählen hinter dem hostnamen verhindert.

Möglicherweise könnte auch das Posting vom 26.07.2023 die Lösung sein, als Alternative zum neustart von avahi. Ich habe es noch nicht getestet.

Ergo: es ist kein macOS bug, wie immer wieder gerne behauptet wird, sondern eine schlechte Implementierung von avahi, die halt unter macOS auffällt, weil macOS sowas über Bonjour regelt.

Wenn ich mich recht erinnere, macht es z.B. das openmediavault-plugin autoshutdown ebenso. (es kann auch sein, dass ich das nur selbst als patch geschrieben habe. Ich nutze das plugin nicht mehr, da es am Raspi sinnlos ist)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
Könnte auch einfach daran liegen dass in /Volumes bereits NAS-Datenspeicher vorhanden ist und macOS dann eben NAS-Datenspeicher-2 nimmt.
 
  • Gefällt mir
Reaktionen: dg2rbf
Es wird aber an avahi liegen.
Hört sich plausibel an.
Chronosync und CarbonCopyCloner greifen via IP6 zu und haben Fehler geliefert.
  • Bei IPv6 spielen DHCP und (feste oder dynamische) IPv4-Adressen keine Rolle.
  • Mglw. annonciert avahi geänderte IPv6-Adressen nicht oder zu spät und der Automount läuft in die Irre.
  • Der Mac glaubt, dass er es mit einem anderen Netzwerk-Host zu tun hat und "erfindet" das "-1"/"-2"-Suffix auf dem Volume-Namen.
 
  • Gefällt mir
Reaktionen: joergSt
Bei IPv6 spielen DHCP und (feste oder dynamische) IPv4-Adressen keine Rolle.

ja.

Im oben verlinkten Thread ist im Posting vom 26.7.2023 ein workaround vorhanden, der, so wie ich das sehe, genau auf das abzielt. Dort wird dann kein AAAA record mit IPv4 announce gesendet und kein A record bie IPv6 announce.

Allerdings frage ich mich auch, warum überhaupt ein AAAA bei IPv4 bzw. ein A record bei IPv6 mit announciert wird.
 
  • Gefällt mir
Reaktionen: dg2rbf und joergSt
warum überhaupt ein AAAA bei IPv4 bzw. ein A record bei IPv6 mit announciert wird.
interessant ...

Spurious name conflicts · Issue #117 · lathiatavahi · GitHub.png
 
  • Gefällt mir
Reaktionen: joergSt
war eine weile im off und "musste" warten, bis das problem wieder auftaucht, heute wars denn so weit.

ich habe die avahi-daemon.conf geändert, allerdings war
Code:
publish-a-on-ipv6=no
schon gesetzt, so das ich nur
Code:
publish-aaaa-on-ip4
auf no geändert habe. bin gespannt ob es das löst

Danke an euch all alle für die Hinweise und Tipps!
 
muss leider sagen, das war ein Satz mit x.. die beiden Parameter auf "no" zu setzen hat keinerlei Änderung gebracht, nach dem ich den Rechner gerade gestartet habe, heisst das Ding schon wieder /fileserver-2... mhhh
 
muss leider sagen, das war ein Satz mit x.. die beiden Parameter auf "no" zu setzen hat keinerlei Änderung gebracht, nach dem ich den Rechner gerade gestartet habe, heisst das Ding schon wieder /fileserver-2... mhhh

Du musst auch den Server neu starten.

Überpüfe auch mal, ob du in deinem LAN noch einen weiteren avahi-daemon laufen hast. Docker-Container sind da gerne vergessen.
 
  • Gefällt mir
Reaktionen: joergSt und dg2rbf
Zurück
Oben Unten