Einrichtung von OpenMediaVault

  • Ich habe auf meinem neuen Raspi 5/8GB OpenMediaVault neu eingerichtet. Ich bin dabei wie beim Pi 3 vorgegangen: nach Installation der aktuellen Lite-Version habe ich mit dem github-Script OMV installiert und dabei eine fest zugeteilte LAN-Netzwerkverbindung genutzt. Danach konnte ich über meinen Webbrowser (MS-Edge) die Startseite von OMV sofort erreichen und auch die ersten Änderungen (21) einspielen.

    Dann begann mein Problem: bei Übernahme der anstehenden Konfigurationsänderungen ist nach minutenlanger Wartezeit ein Softwarefehler angezeigt worden, der anscheinend zum Abbruch der Netzwerkverbindung geführt hat. Seit diesem Zeitpunkt ist der Server (Raspi) auch über SSH (Putty) nicht mehr erreichbar. Auch der Pingbefehl unter seiner Netzwerkadresse zeigt keine Verbindung mehr.

    Meine rudimentären Netzwerkkenntnisse bringen mich jetzt nicht mehr weiter. Deswegen meine Hoffnung, dass mir hier aus dem Forum heraus weitergeholfen werden kann.

    Herzlichen Dank im voraus

    Josl

  • Ich habe bei meinen mehrfachen Neuinstallationen auch einen Reboot (Neustart) von OMV durchgeführt, bevor ich die angezeigten Änderungen eingespielt und übernommen habe. Auch dabei kommt die beschriebene Fehlermeldung.
    Eigentlich ist die gesamte Installation mit dem github-Script nicht besonders schwierig, sie hat ja mit der gleichen Vorgehensweise auch beim Vorgänger Pi3+ unter Bookworm auf anhieb geklappt.
    Es scheint so zu sein, dass sowohl beim manuellen Reboot als auch beim automatischen Herunterfahren nach Übernahme der Konfigurationsänderungen die Verbindung zum Raspi/OMV abreißt. Die Netzwerkadresse des Raspi habe ich ganz am Anfang in der Fritzbox fest zugewiesen.

    Hätte ich es bloß beim alten System belassen!

    Josl

  • Mein Netzwerkproblem beginnt anscheinend schon vor der OMV-Installation. Ich kann über SSH/Putty auf die Raspi-Oberfläche zugreifen. Dabei erscheint zunächst ein Sicherheitshinweis, den ich mit Accept bestätige. Dann kann ich alle Einstellungen auf dem Raspi vornehmen. Sobald ich aber einen Reboot starte, bricht die Netzwerkverbindung ab und der Raspi ist nicht mehr erreichbar. Erst nach einem harten Restart komme ich wieder auf dessen Oberfläche, dieses Mal aber ohne dem Warnhinweis. Ein neuer Reboot führt jedoch wieder zum Abbruch der Netzwerkverbindung.

    Wo könnte das Problem liegen?

    Ich hoffe und baue auf Eure größeren Erfahrungen!

    Josl



  • Wahrscheinlich liegt mein Problem nicht bei Raspi/OMV, sondern auf der Netzwerkebene meines neuen PC mit Win11 pro. Beim erstmaligen Start von OMV kann ich zwar den Raspi unter seiner IP-Adresse mit ping-Befehl erreichen. In der Netzwerkübersicht auf dem Desktop wird er aber trotzdem nicht aufgelistet - im Gegensatz zu allen anderen Geräten in meinem Heimnetzwerk.

    Die Fehlersuche werde ich deshalb auf die Windows Ebene verlegen.

    Herzlichen Dank an alle, die sich schon mit dem wahrscheinlich unzutreffenden Problemfeld befasst haben. Netzwerkfragen führen mich immer in einen wissensmäßigen Blindflug, wenn die Geräteerkennung nicht automatisch funktioniert.

    Josl

  • In der Netzwerkübersicht auf dem Desktop wird er aber trotzdem nicht aufgelistet - im Gegensatz zu allen anderen Geräten in meinem Heimnetzwerk.

    Die Fehlersuche werde ich deshalb auf die Windows Ebene verlegen.

    Poste mal aus der power shell deines Win 11, die Ausgaben von:

    Code
    arp -a
    # und die von
    Get-NetNeighbor

    Wie ist z. Zt. dein PI5 mit der FritzBox verbunden?

    EDIT:

    BTW: Kann es evtl. sein, dass das Frontend das Du auf deinem PI5 benutzt, "mac-address-randomization" macht, die insbesondere bei einem reboot zum tragen kommt?

    Wi-Fi_Signal_Strength  txpower
    iptables chains order scheme iptables-diagram
    nftables-diagram

    Meine PIs

    PI4B/8GB (border device) FreeBSD 15.1R-p1 (arm64): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI4B/4GB FreeBSD 14.4R-p7 (arm64): SSH-Serv., WireGuard-Serv., ngircd-Serv., Mumble-Serv., ddclient

    PI4B/8GB Bookworm-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

    Edited once, last by rpi444 (July 7, 2026 at 11:02 AM).

  • Hallo rpi444

    zunächst danke, dass du mir bei meinen Win-Netzwerkproblemen zur Seite stehst.

    Mein Raspi5-8GB hängt per LAN an der Fritzbox 7590 und hat die fest zugewiesene Adresse 192.168.178.21. Der ping-Befehl auf diese Adresse wird zunächst auch beantwortet. Nach einem Reboot allerdings nicht mehr.

    Wie kann ich feststellen, ob mein Pi5 "mac-address-randomization" macht?

    Herzliche Grüße

    Josl


  • BTW: Warum erlaubst Du in deiner FritzBox, die selbstständige Portfreigabe an LAN 4, für deinen PI5?

    Schau auf deinem PI5 mit ethtool nach, ob EEE für das eth0-Interface aktiv ist:

    Code
    sudo ethtool --show-eee eth0
    Quote

    "EEE status: disabled" oder "EEE status: enabled - active" ?

    Installiere auf deinem Win11 ein tool (nmap oder arp-scan oder gleichwertig), mit dem Du testen kannst, ob Geräte die mit "arp -a" (in Win 11) gerade nicht angezeigt werden, im Subnetz deiner FritzBox per arpscan trotzdem erreicht werden können.

    1. Schalte die selbstständige Portfreigabe aus, da gibt es keinen Grund für.
    2. Zu deinem ersten Screenshot in Post#4: wenn ich in der Windows Powershell arbeite, bekomme ich diese Meldung, wenn sich am Pi was geändert hat. Dann kann man die Datei known_hosts im Verzeichnis %USERPROFILE%\.ssh löschen oder nur die betreffende Zeile, die in der Powershell genannt wird.
      Ob Putty da sein eigenes Ding macht kann ich nicht sagen.
  • Hi rpi444,

    die selbständige Portfreigabe habe ich aus den vorangegangenen Einstellungen in der Fritzbox für den Raspi-Vorgängers (pi3) übernommen. Dies geschah in der Absicht, diesen aus dem Internet (über MyFritz) erreichbar zu machen. Derartige Pläne verfolge ich - zumindestens derzeit - nicht, weshalb ich diese Einstellungen in der Fritzbox nun entfernt habe. Allerdings hat sich an der grundlegenden Situation nichts geändert.

    Bis zum Wechsel auf den AsusNuc habe ich den alten Pi3 an mindestens 2 PC's genutzt, davon ein relativ alter mit Win 10. Bei allen PC-Vorgängern hatte ich keinerlei Probleme mit der Netzwerkerkennung des Pi. Ebenso hat damals die Installation von OMV - trotz meiner Unerfahrenheit auf diesem Gebiet - reibungslos funktioniert. Deswegen macht mich die jetzige Situation mit einem modernen PC-System relativ ratlos.

    Gibt ein Test mit den von Dir genannten tools Sinn, wenn bereits der pingtest unter Windows die Erreichbarkeit des Pi5 bestätigt? Die Antwortzeit auf die Testanfrage liegt unter 1 ms.

    Im heimischen Netzwerk befindet sich noch ein alter Pi3, auf dem OpenCCU (=Homematicnachfolger) läuft. Dieser ist von allen Geräten aus erreichbar und ist seit eher 10 Jahren auch auf allen PC-Vorgängern reibungslos gelaufen.

    Was ist jetzt mit dem Pi5 anders?

    P.S.: als Blockierer hatte ich auch die Windows-Firewall in Erwägung gezogen und sie deshalb versuchsweise deaktiviert - ohne Auswirkung!

    LG

    Josl

  • Allerdings hat sich an der grundlegenden Situation nichts geändert.

    Ja, denn das war nur ein allgemeiner Hinweis, der mit deinem Problem nichts zu tun hat.

    Gibt ein Test mit den von Dir genannten tools Sinn, wenn bereits der pingtest unter Windows die Erreichbarkeit des Pi5 bestätigt? Die Antwortzeit auf die Testanfrage liegt unter 1 ms.

    Es geht ja um die Erreichbarkeit deines PI5, wenn dieser rebootet hat. Kannst Du den PI5 nach einem reboot (mit z. B. sudo shutdown -r +1) per ping wieder erreichen oder musstest Du ein hard reset machen?

    Was ist jetzt mit dem Pi5 anders?

    Ändere in der config.txt deines PI5:

    Code
    dtparam=eee=off

    (so dass das EEE persistent deaktiviert ist). Reboote deinen PI5 mit:

    Code
    sudo shutdown -r +1

    und teste danach ob der PI5 nach dem reboot per ping (icmp) oder per arp-scan (arp) oder gleichwertig, aus dem Subnetz deiner FritzBox erreichbar ist. Wenn nicht, muss man sich das Frontend(gedöns) mit dem Du den Netzwerkzugang auf deinem PI5 konfigurierst, genauer anschauen.

    EDIT:

    Mit nmap auf deinem Win 11 könntest Du arpingen (... mit nping). Z. B.:

    Code
    winget install Insecure.Nmap
    Code
    nping --arp-type ARP-request 192.168.178.1   # als Test!
    Code
    nping --arp-type ARP-request 192.168.178.21

    arp-scan ins Subnetz der FritzBox:

    Code
    nmap -sn -PR 192.168.178.0/24

    BTW: Du könntest auch WSL 2 (Windows-Subsystem für Linux (Version 2)) in deinem Win 11 installieren (Debian 13)/konfigurieren und benutzen: https://learn.microsoft.com/de-de/windows/wsl/

    Wi-Fi_Signal_Strength  txpower
    iptables chains order scheme iptables-diagram
    nftables-diagram

    Meine PIs

    PI4B/8GB (border device) FreeBSD 15.1R-p1 (arm64): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI4B/4GB FreeBSD 14.4R-p7 (arm64): SSH-Serv., WireGuard-Serv., ngircd-Serv., Mumble-Serv., ddclient

    PI4B/8GB Bookworm-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

    Edited 2 times, last by rpi444 (July 7, 2026 at 3:05 PM).

  • Hallo rpi444,

    allmählich brauche ich etwas Abstand zu meinem Problemfeld. Jetzt aber zu den einfacheren Dingen: nach dem shutdown meldet das putty-Terminal "Remote side unexpectedly closed network connection", trotzdem kann ich den Raspi mit dem ping-Befehl unter seiner Adresse erreichen. Eingaben auf dem putty-Terminal sind dagegen nicht mehr möglich. Erst wenn ich putty schließe und neu starte (ohne hardware reset) kann ich wieder auf die Raspi-Oberfläche zugreifen.

    Über den Webbrowser (auch Safari unter MacOs) war er in keiner Situation erreichbar.

    Für die noch ausstehenden Versuche werde ich auf dem Raspi nur die Lite-Version von Trixie installieren. OMV bleibt solange außen vor, bis ich hoffentlich irgendwann mein Netzwerkproblem gelöst habe.

    Nach einer Nachdenkpause werde ich mich wieder melden.

    Bis dahin

    Josl

  • trotzdem kann ich den Raspi mit dem ping-Befehl unter seiner Adresse erreichen. Eingaben auf dem putty-Terminal sind dagegen nicht mehr möglich. Erst wenn ich putty schließe und neu starte (ohne hardware reset) kann ich wieder auf die Raspi-Oberfläche zugreifen.

    Das ist normal, die alte ssh-Verbindung ist ja durch den Reboot geschlossen worden. Schließen von Putty und neu starten ist aber nicht unbedingt nötig. Klick links oben und dann auf "Restart Session".

    Und bitte poste Deine Terminal-Ausgaben als Text in einem Codeblock und nicht als Bildschirmfotos. Dann fällt es leichter, da Zeilen rauszusuchen und zu kommentieren, ohne das selbst wieder abtippen zu müssen.

    Z.B. solltest Du nicht sudo shutdown -r +r eintippen, sondern sudo shutdown -r +1 Die +1 geben die Zeitdauer bis Restart in Minuten, das ist aber ohnehin der Default. Die Angabe dann wegzulassen war also in Ordnung.

    Everybody's moving
    Everybody's moving
    Everybody's moving, moving, moving, moving
    Please don't leave me to remain

  • Z.B. solltest Du nicht sudo shutdown -r +r eintippen, sondern sudo shutdown -r +1 Die +1 geben die Zeitdauer bis Restart in Minuten, das ist aber ohnehin der Default. Die Angabe dann wegzulassen war also in Ordnung.


    Oder für sofortigen Neustart:

    Bash
    sudo shutdown -r now

    Varianten:

    Code
    sudo shutdown -r +0

    oder

    Code
    sudo reboot

    Ich nehme allerdings inzwischen meistens die Default-Wartezeit, benutze also sudo shutdown -r. Dann bleiben noch ein paar Sekunden um zu merken, dass ich das eigentlich auf einem anderen Rechner vorhatte. ;) Und ich kann dann noch sudo shutdown -c nutzen.

    Edit: den wichtigeren Grund vergessen. Ich bin öfter mal von verschiedenen Geräte aus beim gleichen RPi eingeloggt. Und manchmal fällt mir das noch rechtzeitig ein, um den Shutdown abzubrechen.

    Everybody's moving
    Everybody's moving
    Everybody's moving, moving, moving, moving
    Please don't leave me to remain

    Edited once, last by DistroEx (July 8, 2026 at 2:01 PM).

  • ...: nach dem shutdown ..., trotzdem kann ich den Raspi mit dem ping-Befehl unter seiner Adresse erreichen.

    In deinem Beitrag #7 hast Du noch geschrieben:

    Quote

    Der ping-Befehl auf diese Adresse wird zunächst auch beantwortet. Nach einem Reboot allerdings nicht mehr.

    Was hast Du jetzt geändert/gemacht bzw. konfiguriert, weil Du deinen PI5 nach einem "normalen" Reboot, per ping (icmp) erreichen kannst?

    Über den Webbrowser (auch Safari unter MacOs) war er in keiner Situation erreichbar.

    Mach mal von deinem Mac einen Portscan auf die TCP-Ports 80 und 443 deines PI5. Im MacOS hast Du netcat (nc) schon an Bord, so dass Du es benutzen kannst. Z. B.:

    Code
    nc -zv 192.168.178.21 443
    nc -zv 192.168.178.21 80
    nc -zv 192.168.178.21 22

    ?

    EDIT:

    Z. B.:

    Code
    :~$ nc -zvn 192.168.178.4 22
    (UNKNOWN) [192.168.178.4] 22 (ssh) open

    Wi-Fi_Signal_Strength  txpower
    iptables chains order scheme iptables-diagram
    nftables-diagram

    Meine PIs

    PI4B/8GB (border device) FreeBSD 15.1R-p1 (arm64): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI4B/4GB FreeBSD 14.4R-p7 (arm64): SSH-Serv., WireGuard-Serv., ngircd-Serv., Mumble-Serv., ddclient

    PI4B/8GB Bookworm-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

    Edited 2 times, last by rpi444 (July 8, 2026 at 10:22 AM).

  • Hallo rpi444,

    zum ping-Test: wenn ich diesen von der OMV-Oberfläche aus starte, hängt sich das gesamte System auf. Es ist dann nicht mehr über den ping-Befehl erreichbar. Dann hilft auch schließen der putty-Oberfläche nicht mehr. Anders dagegen, wenn ich von putty aus den reboot starte, dann bleibt der Raspi mit dem ping-Befehl ansprechbar. Nach neuem Öffnen von putty kann ich auch auf den Raspi wieder zugreifen.

    Dies alles ist nicht mehr möglich, wenn ich einen reboot aus OMV heraus starte, oder der reboot nach einspielen der ersten (23) Updates automatisch durchgeführt wird.

    Das alles nervt mich zwischenzeitlich derart, weshalb ich einen Schritt zurückgegangen bin und auf einem Raspi4-8GB Debian Bookworm installiert und darauf das GithubScript für die OMV Version 7 eingespielt habe. Bis auf die Anzeige dieses Gerätes in der Windows Netzwerkübersicht funktioniert hier alles. Im Unterschied zur Version 8 wird hier nach dem automatischen Reboot zwar auch eine Serverunterbrechung (rote Schrift) signalisiert, unmittelbar dahinter aber erscheint wieder die OMV-Bedienoberfläche. Bei der Version 8 bleibt hier die Anzeige Softwarefehler....... stehen und alles ist blockiert!

    Ich danke Dir ausdrücklich für die Geduld und Mühen die Du in dieser Angelegenheit bisher schon aufgebracht hast. Ich jedenfalls stelle das ganze Thema für einige Zeit einmal zurück. Mögliche Softwarefehler - auch mit Deiner Hilfe - zu korrigieren, ist nicht so meine Sache. Hätte ich es bloß beim alten System belassen: never touch a running system!

    LG

    Josl

  • Nun habe ich Bookworm und OMV7 auch noch versuchsweise auf dem Pi5 installiert: funktioniert auf Anhieb! Es bleibt nur noch die fehlende Anzeige in der Win Netzwerkübersicht. Irgendwo auf der Strecke Trixie/OMV scheint es einen Fehler zu geben. Jetzt bleibt mir nur noch die Entscheidung, mit der älteren Software auf dem neuen Pi5 weiterzumachen oder auf eine Fehlerbereinigung in Zukunft zu hoffen.

    Auf jeden Fall brauche ich jetzt einmal eine Pause!

    Herzliche Grüße ins Forum und insbesondere an rpi444

    Josl

  • Josl Zu deinem Ausgnagsposting: Ich habe heute OMV auf einem anderen Pi5 neu aufgesetzt und nach dem Login in OMV und dem akkzeptieren der pending changes und der Installation von 4 Updates innerhalb OMV habe ich auch die rote Fehlermeldung bekommen. Ein Klick mit der linken Maustaste hat die Loginseite von OMV neu geladen und ich konnte mich normal anmelden.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!