Nach NAS (omv) upgrade: NAS nicht mehr über Namen zu verbinden-über IP geht

jteschner

jteschner

Aktives Mitglied
Thread Starter
Dabei seit
30.05.2006
Beiträge
4.039
Reaktionspunkte
2.426
Ich habe mein Raspi-NAS von OMV6/Bullseye auf OMV7/Bookworm aktualisieren lassen ("omv-release-upgrade" - natürlich zunächst testweise auf einer Kopie des Systems).
Der upgrade ist ohne Fehler durchgelaufen, ein Reboot startete problemlos.

Allerdings zeigt der Finder das NAS (Name bei mir "omv") auf dem MBP (Sonoma) nun nicht mehr als Netzwerk-Device an.
Was ein "Major Issue" für mich ist: Timemachine findet das NAS nicht mehr und kann daher nicht mehr sichern.

Über IP-Adresse ist aber alles möglich (webzugriff, SMB-Freigaben verbinden, ...) - heisst für mich: auf Seiten des NAS ist alles vermeindlich soweit ok.

Vor dem Upgrade konnte ich über "omv.local" das NAS vom MBP aus erreichen
Ein "ping omv.local" bringt nun: "cannot resolve omv.local: Unknown host"


Was ich bislang versucht habe:
- avahi auf dem NAS neu gestartet
- MBP, FritzBox, piHole, NAS neu gestartet
- in FritzBox das NAS in den NW-Einstellungen gelöscht und neu verbinden lassen
- auf dem NAS mal eine neue Freigabe erstellt und über SMB verfügbar gemacht
- von einem anderen Linux system ist ein "ping omv" möglich - heisst: Name wird im NW aufgelöst
- um auszuschließen, dass es an "Bookworm" liegt: -> ping vom MBP auf anderen Linux-Raspi mit Bookworm: geht (ping desktop.local)
- Synology NAS mit Namen "DS716II" kann ebenfalls über "ping DS716II.local" vom MBP angepingt werden

Alles ohne Erfolg.
Kann mir jemand sagen was ich noch tun kann?
 
Zuletzt bearbeitet:
niemand einen Tip?
Inzwischen habe ich meine Original-System-SSD mit OMV6/Bullseye wieder angeschlossen - alle Probleme verschwunden ...
Aber wenn ein Tip kommt, werde ich das andere Bootdevice mit OMV7/Bookworm anschließen und weiter testen.
Interessiert mich ja schon woran es liegen könnte.
Ansonsten würde ich bei Gelegenheit mal Bookworm/OMV7 komplett von Scratch neu aufsetzen - ist halt nur mehr Aufwand ...
 
Hast du Private Relay eingeschaltet? Das war bei mir auch z.B. bei "fritz.box". Nach dem Ausschalten klappte es wieder.
 
Hast du Private Relay eingeschaltet? Das war bei mir auch z.B. bei "fritz.box". Nach dem Ausschalten klappte es wieder.
Nein, so etwas habe ich nicht.
Aber nochmal kurz zusammengefasst:
Alle Namen meiner Geräte im NW werden vom MBP sauber aufgelöst - nur dieser vertrackte RPi mit OMV nicht (nach dem System-Upgrade).
Auch meine andereren RPi mit homebridge und piHole --> homebridge.local (Bullseye) und mein RPi auf dem Schreibtisch --> desktop.local (Bookworm)

Ich habe auch nichts im Netz verändert. Nur das OMV-Upgrade gemacht -> und der eine RPi ist nur noch über IP ansprechbar
was mich ja gar nicht soooo stören würde - nur Timemachine sichert dann nicht mehr darauf
 
ich habe einfach zu wenig Ahnung von Netzwerken ...
Aber könnte es sein, dass piHole da eine Rolle spielt und irgendwie den Namen nicht auflöst? Warum auch immer ...
Ich habe ja auch diese ".local" domain nirgends (bewusst) eingetragen und die kommt ja wohl eher nicht von der Fritze
 
Antwort von KI:
Im Netzwerk wird die .local Domain durch den Multicast Domain Name Service (mDNS) verwendet. Hosts, die mDNS implementieren, nutzen .local als Domainnamen und haben ihre eigene Methode, Namen aufzulösen1. Es ist wichtig zu beachten, dass die .local Domain für die Verwendung mit mDNS reserviert ist und nicht für normales DNS verwendet werden sollte2. Für interne Netzwerke ist es besser, eine Subdomäne einer eigenen registrierten Domäne zu verwenden, zum Beispiel local.meinedomäne.de.
 
Antwort von KI:
Im Netzwerk wird die .local Domain durch den Multicast Domain Name Service (mDNS) verwendet. Hosts, die mDNS implementieren, nutzen .local als Domainnamen und haben ihre eigene Methode, Namen aufzulösen1. Es ist wichtig zu beachten, dass die .local Domain für die Verwendung mit mDNS reserviert ist und nicht für normales DNS verwendet werden sollte2. Für interne Netzwerke ist es besser, eine Subdomäne einer eigenen registrierten Domäne zu verwenden, zum Beispiel local.meinedomäne.de.
hmmm - ich sehe noch nicht, wie mir das hilft.
avahi hatte ich ja bereits neu gestartet (auf dem RPi)
 
Niemand mehr eine Idee?
@lisanet : Du vielleicht? Oder möchtest du lieber eine ausufernde Fehlersuche vermeiden? Könnte ich auch verstehen ...
 
ich bin unterwegs mit dem iPhone.

Nur 2 Dinge:

du bist mutig mit Debian 12 und omv, da sich dort viel zum Netzwerk geändert hat.

Geändert hat sich AFAIK genau das hinsichtlich des resolvers und damit muss auch das Zusammenspiel zwischen avahi und dem Debian-systemseitigen resolver angepasst werden.

Ich habe mich damit nich nicht tiefer befasst, als ich diese Änderung erfahren habe und das update auf omv 7 erst mal zurück gestellt.

Anmerkung:
Solche grundlegenden Änderungen ohne einfachen, automatischen Migrationspfad sind mit ein Grund, warum Linux niemals auf den Desktop von Usern kommt.

Für Freaks und Frickler ist das eine tolle Beschäftigung, aber für User der Horror. Und wenn dann noch sowas dazu kommt wie macOS Standards wie bonjour, dann ist es im Linux-Umfeld eh vorbei. Da kennt ein richtiger Admin die IP-Adressen seiner Geräte auswendig, auch die IPv6
 
  • Gefällt mir
Reaktionen: secretsquirrel, JARVIS1187, win2mac und 2 andere
Die Wunderlösung habe ich auch nicht, nur eine Beobachtung:

- Neulich wurden aus unerfindlichem Grund (evtl. nach einem MacOS Security-Update??) die NetBIOS-Namen ( "server", ohne Punkte) nicht mehr vernünftig aufgelöst
- "server.local" war immer noch Ok, sowohl IPv4 als auch IPv6, "server" war garnix.
- "server.fritz.box" zeigt irgendwohin in den Wald.

Ein Zusammenhang mit dem aktuell wechselnden "fritz.box"-Mist ist nicht auszuschließen. Meine Suchdomain auf der Fritzbox ist immer noch "fritz.box" und da schrauben sie ständig drauf rum. PiHole ist hier ebenfalls im Einsatz.

Mangels Zeit und Gelegenheit habe ich als Workaround an den notwendigen Stellen den NetBIOS-Namen jeweils durch "server.local" ersetzt und alles war paletti.
 
  • Gefällt mir
Reaktionen: jteschner
du bist mutig mit Debian 12 und omv, da sich dort viel zum Netzwerk geändert hat.
Na ja, so viel Mut war es nicht - ich habe ja meine funktionierende Original-OMV6-System-SSD nicht angerührt, sondern auf einem Klon die "Versuche" gemacht ;-)
Geändert hat sich AFAIK genau das hinsichtlich des resolvers und damit muss auch das Zusammenspiel zwischen avahi und dem Debian-systemseitigen resolver angepasst werden.
So sieht es wohl aus
Ich habe mich damit nich nicht tiefer befasst, als ich diese Änderung erfahren habe und das update auf omv 7 erst mal zurück gestellt.
Schade aber klug - nur könnte es ja sein, dass du eine Idee hast.

Der upgrade OMV6 -> OMV7 ist ja eigentlich durch "omv-release-upgrade" sehr einfach und läuft auch durch. Alles funzt omv-seitig - nur die Namensauflösung auf macOS Seite nicht mehr. Und die OMV-Leute können auch nicht weiter helfen in Ermangelung von Apple-HW.

Nebenbei:
Ich habe inzwischen mal probiert (nach Anleitung):
- Neuinstallation Bookworm
- Neuinstallation omv7
- omv-regen regenerate (mit Restore aus entsprechendem Backup)

--> omv-regen bringt Fehler:
Code:
[ERROR   ] Command '/usr/bin/systemd-run' failed with return code: 1
[ERROR   ] stderr: Running scope as unit: run-rbad30fd91cb94ae6a1c7855d91ae1bc7.scope
Job for avahi-daemon.service failed because the control process exited with error code.
See "systemctl status avahi-daemon.service" and "journalctl -xeu avahi-daemon.service" for details.
[ERROR   ] retcode: 1
[ERROR   ] Job for avahi-daemon.service failed because the control process exited with error code.
See "systemctl status avahi-daemon.service" and "journalctl -xeu avahi-daemon.service" for details.

Geht so also auch nicht einfach mal ...
Weiter habe ich nun nicht mehr probiert und omv6 wieder in Betrieb genommen.
 
...

Mangels Zeit und Gelegenheit habe ich als Workaround an den notwendigen Stellen den NetBIOS-Namen jeweils durch "server.local" ersetzt und alles war paletti.
Mangels notwendigem Wissen frage ich mal: heißt konkret? Was sind diese "Stellen"? Könnte ich ja mal probieren ...
 
was auch sein kann:

schau mal nach ob omv überhaupt den Netzwerkport in der avahi-config richtig frei geheben hat

ich meine mich zu erinnern, dass debian 12 die Bezeichnung der Ports verändert hat.
 
  • Gefällt mir
Reaktionen: jteschner
Na ja, so viel Mut war es nicht - ich habe ja meine funktionierende Original-OMV6-System-SSD nicht angerührt, sondern auf einem Klon die "Versuche" gemacht ;-)

So sieht es wohl aus

Schade aber klug - nur könnte es ja sein, dass du eine Idee hast.

Der upgrade OMV6 -> OMV7 ist ja eigentlich durch "omv-release-upgrade" sehr einfach und läuft auch durch. Alles funzt omv-seitig - nur die Namensauflösung auf macOS Seite nicht mehr. Und die OMV-Leute können auch nicht weiter helfen in Ermangelung von Apple-HW.

Nebenbei:
Ich habe inzwischen mal probiert (nach Anleitung):
- Neuinstallation Bookworm
- Neuinstallation omv7
- omv-regen regenerate (mit Restore aus entsprechendem Backup)

--> omv-regen bringt Fehler:
Code:
[ERROR   ] Command '/usr/bin/systemd-run' failed with return code: 1
[ERROR   ] stderr: Running scope as unit: run-rbad30fd91cb94ae6a1c7855d91ae1bc7.scope
Job for avahi-daemon.service failed because the control process exited with error code.
See "systemctl status avahi-daemon.service" and "journalctl -xeu avahi-daemon.service" for details.
[ERROR   ] retcode: 1
[ERROR   ] Job for avahi-daemon.service failed because the control process exited with error code.
See "systemctl status avahi-daemon.service" and "journalctl -xeu avahi-daemon.service" for details.

Geht so also auch nicht einfach mal ...
Weiter habe ich nun nicht mehr probiert und omv6 wieder in Betrieb genommen.

schau dir auch mal das log an, mit den Befehlen, die in der Ausgabe erwähnt werden
 
schau dir auch mal das log an, mit den Befehlen, die in der Ausgabe erwähnt werden
Das geht leider nicht (mehr) da der RPi hängen geblieben ist und nicht mehr komplett startet - dann müsste ich einen Monitor(Keyboard dranhängen und das ist etwas problematisch.

Ich schaue erstmal nach der avahi Konfig und vergleiche meinen "Test-RPi" mit Debian12 (bei dem funktioniert die Namensauflösung) und dem "OMV7-Debian12-RPi" (das ist noch über eine SD-Karte bootbar).
Das ist ja im Prinizip das, was mich wundert: beide RPi auf Debian12 und nur bei einem geht es nicht.

Mache ich aber morgen erst.
 
(re. NetBIOS-Name funkt nicht mehr)
heißt konkret? Was sind diese "Stellen"?
Einfach überall, wo "server" drin vorkommt, "server.local" reinschreiben.

In Shell-Skripten z.B. per
Code:
open smb://server.local/share

Per "Gehe zu - Mit Server verbinden"
Code:
smb://server.local/share

Per Automounter (o.ä., benutze ich nicht) ganz analog

Anmeldeobjekte (oder wie das heißt) ggf. ersetzen.

------------------
Nach meiner unmaßgeblichen Meinung sind (punktlose) NetBIOS-Namen auf dem Mac eher etwas aufgepfropft. Unix-typisch wären FQDN-Namen (mit Punkten).
Und irgendwas.local ist dann noch Bonjour/mDNS-typisch und kann im eigenen Netzwerk nicht verkehrt sein.

Mit dem Tool "Discovery - DNS-SD Browser" kann man mal bisschen spinxen, was Bonjour eigentlich so macht.
 
(re. NetBIOS-Name funkt nicht mehr)

Einfach überall, wo "server" drin vorkommt, "server.local" reinschreiben.

In Shell-Skripten z.B. per
Code:
open smb://server.local/share

Per "Gehe zu - Mit Server verbinden"
Code:
smb://server.local/share

Per Automounter (o.ä., benutze ich nicht) ganz analog

Anmeldeobjekte (oder wie das heißt) ggf. ersetzen.

------------------
Nach meiner unmaßgeblichen Meinung sind (punktlose) NetBIOS-Namen auf dem Mac eher etwas aufgepfropft. Unix-typisch wären FQDN-Namen (mit Punkten).
Und irgendwas.local ist dann noch Bonjour/mDNS-typisch und kann im eigenen Netzwerk nicht verkehrt sein.

Mit dem Tool "Discovery - DNS-SD Browser" kann man mal bisschen spinxen, was Bonjour eigentlich so macht.
Ach so ...
Nee, das mache ich sowieso immer - das ist ja das Problem: Keine Variante des Namens des einen RPi wird aufgelöst - er kann nur über IP angesprochen werden.
 
ich bin jetzt kein absoluter Netzwerk Spezialist, aber warum trägst du den Server mit der IP nicht in die Hosts Datei auf deinem Mac ein?
Das wäre mein erster Ansatz.
 
  • Gefällt mir
Reaktionen: dg2rbf
Status:
Ich habe nochmal im omv-forum bei den Programmierern einen aktuellen Status gegeben.
Zumindest habe ich schon mal die Rückmeldung erhalten, dass es tatsächlich an der Konfig von OMV7 liegen könnte oder wird.

Da die Kollegen keine macOS Geräte zum testen haben, werden sie nochmal alles bzgl. avahi-konfig checken.
 
  • Gefällt mir
Reaktionen: lisanet
ich bin jetzt kein absoluter Netzwerk Spezialist, aber warum trägst du den Server mit der IP nicht in die Hosts Datei auf deinem Mac ein?
Das wäre mein erster Ansatz.
Das ist zu einfach :)
Nee, im Ernst, werde ich ggf. morgen mal probieren - wäre aber nur eine Krücke, denn zeroconf muss ja funktionieren - und tut es bei den anderen Geräten ja auch.
 
Zurück
Oben Unten