Abgedichtet sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es bislang keine regulären Releases mit dem Fix, da hilft nur der Umstieg auf einen unterstützten Zweig. Auf einem normalen Server erledigt das der Paketmanager. Bei Docker sieht die Sache anders aus: Jeder Container bringt sein eigenes PHP mit, und das bleibt so alt, wie das Image eben ist.

Welcher Container hat welches PHP?

Die erste Frage lautet also: In welchen Containern auf dem Heimserverchen steckt überhaupt ein PHP? Bei Nextcloud oder WordPress ist das klar, bei selbst gebauten Images oder kleinen Web-Apps weniger. Statt jeden Container einzeln abzuklappern, fragt die folgende Schleife alle laufenden Container nach ihrer PHP-Version und gleicht sie gleich mit den gepatchten Versionen ab.

for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  case "${v%.*}" in
    8.5) fix=8.5.12 ;;
    8.4) fix=8.4.27 ;;
    8.3) fix=8.3.36 ;;
    8.2) fix=8.2.35 ;;
    *)   fix=99 ;;
  esac
  if [ "$(printf '%s\n' "$fix" "$v" | sort -V | head -n1)" = "$fix" ]; then
    printf '\e[32m%-30s %-8s ok\e[0m\n' "$c" "$v"
  else
    printf '\e[31m%-30s %-8s anfällig?\e[0m\n' "$c" "$v"
  fi
done

Container ohne PHP überspringt die Schleife stillschweigend. Bei allen anderen landet die Version grün in der Ausgabe, wenn sie mindestens auf dem Stand des Patches ist, und rot, wenn sie darunter liegt. Rot gibt es auch für PHP 8.1, 7.x und älter, denn dafür existiert schlicht kein Fix. Bei mir sieht das Ergebnis so aus:

$ ./php2shell-simple.sh
nextcloud-app-1                8.5.12   ok
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
planetfoss-web                 8.3.33   anfällig?
sisu-web                       8.4.26   anfällig?

Nextcloud und das Test-WordPress hatten ihre Updates also schon gezogen, PlanetFOSS und die Seite für Sisu hingen dagegen noch hinterher. Das Fragezeichen hinter „anfällig“ ist übrigens Absicht. Die Schleife vergleicht nur die Versionsnummer. Nutzt ein Image das PHP-Paket von Debian, Ubuntu oder Alpine, kann der Fix zurückportiert sein, ohne dass sich die Nummer ändert. Dann hilft nur ein Blick in die Sicherheitsmeldungen der Distribution.

Genauer hinschauen lässt sich mit php2shell-check von EXT IT. Das MIT-lizenzierte Skript arbeitet nur lesend und bewertet PHP anhand der Paketversionen statt nur der Versionsnummer, berücksichtigt also auch zurückportierte Fixes. Es schaut in Docker-Container, FPM-Pools und noch laufende alte Prozesse und schickt auf Wunsch eine harmlose Anfrage an eure Website. Für die Container braucht es Root-Rechte oder die Mitgliedschaft in der Gruppe docker.

Die Projektseite schlägt den üblichen Einzeiler mit curl und sudo bash vor. Bei einem Skript, das mit Root-Rechten auf dem Server läuft, mag ich das nicht so gern. Ladet lieber das Skript samt SHA256SUMS aus den Releases herunter, prüft es mit sha256sum -c SHA256SUMS, lest einmal drüber und startet es dann von Hand. Ein „nicht anfällig“ ist laut den Entwicklern übrigens keine Garantie:

$ sudo bash php2shell-check.sh https://eure-seite.example

Auf meinem Heimserver lief das Skript mit sudo. Als Mitglied der Gruppe docker sähe es die Container zwar auch ohne Root-Rechte, laufende Prozesse anderer Benutzer und manche Logs blieben dann aber verborgen. Geholt und gestartet habe ich es so:

$ curl -fsSLO https://github.com/EXT-IT/php2shell-check/releases/latest/download/php2shell-check.sh
$ chmod +x php2shell-check.sh 
$ sudo ./php2shell-check.sh 

Das Urteil deckt sich mit der Schleife: planetfoss-web mit PHP 8.3.33 und sisu-web mit PHP 8.4.26 sind anfällig, Nextcloud und das Test-WordPress nicht. Zusätzlich hat es einen gestoppten Container von Tuxsucht gefunden, den meine Schleife glatt übersehen hat:

PHP in docker containers
  [ OK ] container      nextcloud-app-1 (nextcloud:35-apache)
         PHP 8.5.12 (fixed from 8.5.12)
[...]
  [VULN] container      planetfoss-web (planetfoss-web:local)
         PHP 8.3.33, fixed in 8.3.36
         -> Update PHP to 8.3.36 or later (container: pull the new image and recreate)
[...]
  [VULN] container      sisu-web (sisu-web:local)
         PHP 8.4.26, fixed in 8.4.27
[...]
  [WARN] container      php83 (stopped, tuxsucht-php)
         stopped, but its image ships PHP 8.3.33: it comes back vulnerable on the next start
[...]
Summary  2 vulnerable, 3 undecided, 12 warnings, 11 ok

Klar, docker ps listet eben nur laufende Container, und ein gestoppter Container nimmt keine Anfragen an. Startet ihn aber irgendwann jemand wieder, ist die Lücke sofort zurück. Deutlich wird das Skript außerdem beim Thema mod_php: Alle fünf laufenden Container liefern PHP über das Apache-Modul aus, und genau gegen dieses Setup demonstriert das Advisory einen kompletten Angriff ohne Anmeldung.

Bis zum Update schlägt das Skript als Notbehelf vor, session.upload_progress.enabled=0 und expose_php=0 zu setzen und post_max_size unter einem Viertel von memory_limit zu halten. Die Prüfung von außen hat dagegen wenig gebracht. Für die beiden Websites meldet das Skript nur, dass die Header keine PHP-Version verraten und keine WAF davorsteht. Über den Patchstand sagt das nichts, was das Skript auch ehrlich zugibt.

Und wie bekommt man das PHP aktualisiert?

Im Container selbst solltet ihr nichts aktualisieren, das wäre beim nächsten Neustart wieder weg. Stattdessen zieht ihr im jeweiligen Compose-Verzeichnis das neue Image und baut den Container damit neu auf. Bei selbst gebauten Images mit eigenem Dockerfile braucht es ein docker compose build --pull, damit Docker auch das Basis-Image frisch holt:

$ docker compose pull && docker compose up -d

Wichtig: Das hilft natürlich nur, wenn das Basis-Image die gepatchte Version auch schon enthält. Laut IT-Connect tauchten die neuen Tags anfangs sogar ohne Image dahinter auf, inzwischen liefern allgemeine Tags wie php:8.3-apache das gepatchte PHP. Wer dagegen eine feste Version wie php:8.4.24-fpm im Dockerfile stehen hat, muss sie selbst anheben. Lasst die Schleife nach dem Update einfach noch einmal laufen. Kümmert euch zuerst um die Container, die aus dem Internet erreichbar sind.

Wie das in der Praxis aussieht, zeigt die Testumgebung von PlanetFOSS. Das Image baut auf php:8.3-apache auf und packt im Dockerfile nur noch Erweiterungen wie GD und Intl dazu. Mein Deploy-Skript ruft zwar docker compose up -d --build auf, holt dabei aber kein neues Basis-Image, sondern nimmt das vom August aus dem Cache. Daher stammte das alte PHP 8.3.33. Erst --pull lädt die frische Fassung:

$ cd /data/docker/planetfoss
$ docker compose build --pull web
$ docker compose up -d web

Nach gut einer Minute stand das neue Image, und der Container lief mit PHP 8.3.36. Die Datenbank im selben Compose-Projekt bleibt davon unberührt, weil beide Befehle nur den Dienst web ansprechen. Die Schleife zeigt PlanetFOSS danach grün, und auch php2shell-check meldet nur noch sisu-web als anfällig. Das alte Image liegt übrigens noch als Leiche auf der Platte, docker image prune räumt es weg.

$ ./php2shell-simple.sh
[...]
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
sisu-web                       8.4.26   anfällig?

Alles in allem ist PHP2Shell ein gutes Beispiel dafür, dass Selfhosting mit Docker zwar bequem ist, die Updates aber nicht von allein kommen. Weitere Details zu den Lücken hat heise zusammengetragen. Wie man Container ohne viel Gefrickel auf Stand hält, habe ich mir übrigens in Docker-Container einfach aktuell halten mit Dockcheck angeschaut. Wie haltet ihr eure Container aktuell?

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Warum Sonos S1 noch SMB1 braucht

Bei mir hängen noch zwei Play:3, ein Play:1 und ein Connect:Amp im Netz. Alle laufen mit der S1-Software, für die Sonos nur noch Fehlerkorrekturen liefert. Die Lautsprecher spielen nicht nur Streams, sondern auch meine Musiksammlung vom Server. Laut einer Diskussion im Sonos-Forum reichen die Ressourcen der S1-Geräte dafür aber nur für SMBv1, mehr ist auf der alten Hardware nicht drin.

Samba hat das alte Protokoll dagegen schon lange in Rente geschickt. Seit Version 4.11 steht server min protocol ab Werk auf SMB2_02, die NTLMv1-Anmeldung ist laut Samba-Projekt sogar schon seit Version 4.5 abgeschaltet. Die üblichen Anleitungen schalten beides mit zwei Zeilen global wieder ein. Die Lautsprecher spielen dann zwar, aber eben nicht nur sie bekommen die Tür geöffnet.

Wer ein System mit S2 betreibt, ist fein raus. Sonos hat dort mit Version 13.4.1 im Dezember 2021 SMBv2 und SMBv3 nachgereicht und spricht inzwischen gar kein SMBv1 mehr. S2-User lassen die Samba-Standards also in Ruhe. Der Rest dieses Artikels richtet sich an alle, die wie ich noch an ihren alten Lautsprechern hängen und sie nicht wegen eines Protokolls entsorgen wollen.

Was an der schnellen Lösung das Problem ist

SMB1 lässt sich in Samba nur für den ganzen Server erlauben, nicht für einzelne Freigaben oder Geräte. Spätestens seit WannaCry 2017 eine Lücke in Microsofts SMB1 ausnutzte, gilt das Protokoll als Altlast, und NTLMv1 macht es Angreifern leicht, mitgeschnittene Anmeldungen zu knacken. Meldet sich der Lautsprecher dann auch noch mit eurem normalen Benutzer an, wandert ausgerechnet euer Hauptpasswort im schwächsten Verfahren durchs Netz.

Dazu kommen Zeilen, die man beim Abschreiben gern gleich mitnimmt. Mit wide links und allow insecure wide links folgt Samba Symlinks auch dann, wenn sie aus der Freigabe herauszeigen. Gern hängt auch das ganze Datenverzeichnis schreibbar im Netz. Klar, von außen ist so ein Heimserverchen meist dicht. Doch im selben LAN hängen auch Fernseher, Steckdosen und Lautsprecher, deren Software ihr nicht in der Hand habt.

Ein eigener Benutzer nur für Sonos

Der wichtigste Schritt ist ein eigener Benutzer, der nur für die Lautsprecher da ist und sonst nichts darf. Er braucht weder ein Home-Verzeichnis noch eine Shell, Samba kennt ihn nur zum Anmelden. Das Passwort vergebt ihr einmalig und verwendet es nirgendwo sonst, denn per NTLMv1 sollte man es als halb öffentlich betrachten. Neu anlegen lässt er sich mit zwei Befehlen:

$ sudo useradd -r -M -s /usr/bin/nologin sonos
$ sudo smbpasswd -a sonos

Habt ihr schon einen Benutzer, mit dem sich die Lautsprecher anmelden, stutzt ihr ihn mit usermod zurecht. Er verliert die Shell, bekommt / als Home-Verzeichnis und ein gesperrtes Unix-Passwort. Die Anmeldung an Samba läuft über das eigene Passwort aus smbpasswd und funktioniert davon unberührt weiter. Nutzen die Lautsprecher bisher euren normalen Benutzer, legt ihr dagegen lieber einen neuen an:

$ sudo usermod -s /usr/bin/nologin -d / sonos
$ sudo passwd -l sonos

Die smb.conf

Die Konfiguration erlaubt SMB1 und NTLMv1, grenzt aber alles drumherum ein. Samba lauscht nur auf der LAN-Schnittstelle und nicht auf Docker-Bridges oder VPN-Tunneln. Gäste fliegen raus, Drucker gibt es keine, und jede Freigabe bekommt eine Liste der Benutzer, die rein dürfen. Den Namen der Netzwerkschnittstelle (bei mir enp0s25) und die Pfade müsst ihr natürlich an euer System anpassen:

[global]
   workgroup = WORKGROUP
   server string = bender
   server role = standalone server

   # Sonos S1: nur SMB1 + NTLMv1
   server min protocol = NT1
   server max protocol = SMB3
   ntlm auth = ntlmv1-permitted

   # nur LAN und lokal, nicht auf den Docker-Bridges
   interfaces = lo enp0s25
   bind interfaces only = yes

   map to guest = never

   # keine Drucker
   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes

[homes]
   browseable = no
   writable = yes
   valid users = %S
   invalid users = sonos

[musik]
   path = /data/musik
   browseable = yes
   read only = yes
   valid users = sonos anna ben lena

[data]
   path = /data
   writable = yes
   valid users = anna ben

ntlmv1-permitted ist übrigens nur der sprechende Name für das alte yes. Die Freigabe [musik] ist schreibgeschützt; lesen dürfen sonos und die Familie, hier anna, ben und lena. Selbst wenn jemand die Anmeldung des Lautsprechers knackt, kommt er so nur an die Musik. Auf [data] kommen nur anna und ben, wide links taucht nirgendwo auf, und Symlinks bleiben damit in ihrer Freigabe.

Wichtig ist noch die Zeile invalid users = sonos unter [homes]. Diese Freigabe bietet jedem Benutzer sein Home-Verzeichnis an, und das ist beim Lautsprecher-Benutzer nach dem usermod von oben das Wurzelverzeichnis. Ohne die Zeile gäbe es also eine beschreibbare Freigabe \\bender\sonos auf das ganze System. Was dort tatsächlich geht, regeln zwar die Dateirechte, Verzeichnisse wie /tmp stehen aber für alle offen.

Lässt sich die Sonos-Bibliothek gerade nicht neu einrichten, gibt es auch einen Zwischenschritt ohne eigene Musikfreigabe. Dann nehmt ihr sonos in die valid users der bestehenden Freigabe auf und setzt zusätzlich read list = sonos. Der Lautsprecher darf dann weiter alles lesen, was die Dateirechte hergeben, aber nichts schreiben. Auf Dauer ist die eigene Freigabe aber klar die bessere Wahl.

Bevor ihr die neue Datei aktiviert, lasst ihr sie von testparm prüfen. Das Programm meckert über Tippfehler und unbekannte Optionen, bevor Samba über sie stolpert. Danach startet ihr den Dienst neu, unter Arch heißt er smb, unter Debian und Ubuntu smbd. Offene Verbindungen brechen dabei kurz ab, eingehängte Freigaben auf euren Rechnern verbinden sich aber normalerweise von selbst wieder:

$ sudo testparm -s
$ sudo systemctl restart smb

Die Musikbibliothek in der Sonos-App

Zum Schluss tragt ihr die Freigabe in der S1-App als Musikbibliothek ein. Öffnet dazu die Einstellungen und geht dort auf Musikbibliothek und Musikbibliothek einrichten. Als Pfad tragt ihr die Freigabe im Windows-Format ein, also \\bender\musik, darunter den Benutzer sonos und sein Passwort. Danach liest Sonos die Sammlung ein, was bei großen Bibliotheken etwas dauern kann.

Kontrolle

Ob alles so läuft wie gedacht, zeigt euch smbstatus. In der Spalte Protocol Version seht ihr, wer mit welchem Protokoll angemeldet ist. Normale Rechner sollten sich weiter mit SMB3 verbinden, mein Notebook etwa mit SMB3_11, nur die Lautsprecher tauchen mit NT1 auf. Ein Gastzugriff ohne Passwort sollte dagegen mit NT_STATUS_ACCESS_DENIED abprallen, wenn ihr ihn mit smbclient von einem anderen Rechner aus probiert:

$ sudo smbstatus -b
$ smbclient -N //bender/data -c ls

Vom Ergebnis des zweiten Befehls solltet ihr euch nicht in die Irre führen lassen. Die Zeile „Anonymous login successful“ klingt zwar nach offener Tür, sie betrifft aber nur die Verbindung zum Server selbst, über die ein Client etwa die Liste der Freigaben abfragt. Entscheidend ist die zweite Zeile, denn in die Freigabe selbst kommt ohne Benutzer und Passwort niemand hinein:

$ smbclient -N //bender/data -c ls
Anonymous login successful
tree connect failed: NT_STATUS_ACCESS_DENIED

Bei mir sieht das so aus: Der Lautsprecher im Schlafzimmer liest als sonos per NT1, das Notebook hängt mit SMB3_11 und signierter Verbindung dran. Genau so soll es sein, denn das alte Protokoll bleibt damit auf die Geräte beschränkt, die nichts anderes können. Die übrigen Lautsprecher tauchen erst auf, wenn sie gerade auf die Bibliothek zugreifen:

$ sudo smbstatus -b

Samba version 4.25.0
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------
732192  sonos        sonos        192.168.0.60 (ipv4:192.168.0.60:38427)    NT1               -                    -                    
711090  anna         anna         192.168.0.191 (ipv4:192.168.0.191:52826)  SMB3_11           -                    partial(AES-128-CMAC)

Und auf Dauer?

Ganz glücklich bin ich mit SMB1 natürlich trotzdem nicht. Auf meinem Server läuft ohnehin schon bonob, das Navidrome als Musikdienst in die Sonos-App bringt. Kommt die Musik darüber, braucht kein Lautsprecher mehr eine Samba-Freigabe, und SMB1 könnte endgültig weg. Wer jedoch ohne die interne Sonos-Bibliothek nicht auskommt, für den ist die eingegrenzte Variante in meinen Augen ein guter Kompromiss.

Alles in allem kostet die saubere Variante nur einen Benutzer und ein paar Zeilen mehr in der smb.conf. Die Lautsprecher spielen genauso wie mit der schnellen Lösung, nur führt über sie kein Weg zum Rest des Servers. Wie habt ihr eure alten Sonos-Lautsprecher angebunden? Hängt bei euch auch noch SMB1 im Netz, oder seid ihr längst auf S2 umgestiegen?

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Im Mai 2014 habe ich mir dort einen Account angelegt, seitdem begleitet mich DDNSS. 2016 habe ich den Dienst in den Kommentaren selbst als Anbieter „ohne Nervereien“ weiterempfohlen. Nun liegt eine E-Mail von Robert in meinem Postfach, mit der ich so nicht gerechnet hätte. Nach mehr als 13 Jahren Betrieb steht DDNSS.de vor einer Veränderung: Robert führt derzeit Gespräche über eine mögliche Übernahme des Dienstes.

Übernahme statt Abschaltung

Ein endgültiges Aus ist damit allerdings nicht beschlossen. Spätestens bis zum 31. Oktober 2026 soll eine Entscheidung fallen und die Übergabe geregelt sein – vorausgesetzt, die Gespräche führen zu einem Ergebnis. Kommt die Übernahme zustande, führt der neue Betreiber DDNSS einfach weiter. Scheitern die Gespräche, will Robert rechtzeitig Bescheid geben, damit ihr euch in Ruhe auf einen Wechsel einstellen könnt.

Wer DDNSS in seiner FRITZ!Box oder auf dem eigenen Serverchen eingetragen hat, muss also erst einmal nichts tun. Eure bestehenden DynDNS-Einträge laufen vorerst unverändert weiter, akuten Handlungsbedarf gibt es laut Robert nicht. Rückfragen beantwortet er unter webmaster@ddnss.de. Schaden kann es trotzdem nicht, schon mal nachzusehen, wo bei euch DDNSS überall eingetragen ist – im Router, im ddclient oder in irgendeinem Skript.

Danke, Robert

Leicht fällt Robert der Schritt nicht. Seit Mai 2013 hat er nach eigenen Worten sehr viel Zeit und Arbeit in DDNSS.de gesteckt – ein Geschäftsmodell gab es dabei nie, wer wollte, konnte spenden. Nach über 13 Jahren ist so eine Entscheidung für ihn persönlich alles andere als einfach. Von daher bemüht er sich um eine tragfähige Lösung, statt einfach den Stecker zu ziehen.

Ich möchte mich an dieser Stelle ganz herzlich bei Robert bedanken. In meinen Augen ist es keine Selbstverständlichkeit, so einen kostenlosen Dienst über so viele Jahre am Laufen zu halten. Bei DynDNS merkt man ja meist erst, was man daran hat, wenn es plötzlich nicht mehr funktioniert. Ich hoffe, dass Robert für sein Baby ein ordentliches neues Zuhause findet.

Ich selbst leiste mir inzwischen eine „richtige“ Domain für meine Selfhosting-Aktivitäten. Bei meinem Webhoster geht das recht einfach: Die FRITZ!Box aktualisiert die Einträge meiner eigenen Domain direkt per DynDNS, ein externer Dienst ist dafür nicht mehr nötig. Wer ohnehin eine Domain besitzt, sollte bei seinem Hoster mal nachschauen, ob der so etwas anbietet.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Bevor Fragen aufkommen: Nein, Homarr hat nichts mit dem *arr-Stack zu tun, mit dem so mancher Homelab’er auf hoher See segelt. Kleine Ironie am Rande: Ausgerechnet Sonarr und Radarr dienen in den Release Notes immer wieder als Paradebeispiele für die Integrationen des Dashboards.

Die Entwickler sprechen selbst vom „ultimativen Homarr-Update“. Wer keine Lust auf die ziemlich ausführlichen Release Notes hat, bekommt – O-Ton des Projekts – ein Video für die kurze Aufmerksamkeitsspanne. Es zeigt die wichtigsten Neuerungen von Homarr 2.0 in knapp zwei Minuten im Schnelldurchlauf.

Widgets nach Maß und ein Workshop zum Teilen

Das Herzstück der neuen Version sind die Custom Widgets v2. Eigene Widgets entstehen aus JSX, API-Anfragen, Aktionen und typisierten Einstellungen. Wer nicht selbst programmieren mag, beschreibt dem eingebauten Assistant einfach, was er braucht, und testet das Ergebnis anschließend in einer Art Werkbank.

Genau das macht für mich den Reiz aus: Das Widget-System sieht wesentlich umfangreicher und variabler aus als das von Homepage. Laut den Entwicklern lässt sich damit fast jedes Widget bauen – auch das, welches nur drei Leute brauchen. Die müssen jetzt nicht mehr warten.

Die zweite Hälfte des Konzepts heißt Workshop. Dort veröffentlichen, bewerten und installieren User fertige Widgets und eigenes CSS. Ungetesteter KI-Slop hat dort laut den Entwicklern nichts verloren, der Workshop wird moderiert. Zugangsdaten und Adressen der eigenen Instanz bleiben dabei auf dem eigenen Server.

Ebenfalls neu ist eine Schnittstelle, über die Widgets, Skripte oder KI-Agenten per MCP die gespeicherten Integrationen nutzen. Homarr kennt die Adressen und API-Schlüssel der Dienste ja ohnehin. Es prüft die Rechte, hängt die Zugangsdaten an und reicht die Anfrage weiter, ohne die Schlüssel jemals herauszugeben.

Neuer Board-Editor und viel Kleinkram

Den Board-Editor haben die Entwickler außerdem von Grund auf neu aufgebaut. Das alte Drag-and-Drop flog raus, Verschieben und Skalieren laufen jetzt über dnd-kit und prüfen Kollisionen vor dem Speichern. Gruppen und dynamische Abschnitte weichen sogenannten Containern, und feste Seitenleisten kehren zurück.

Dazu kommen eine neue Ersteinrichtung in sechs Schritten, ein frei konfigurierbarer Header und 31 neue Integrationen, etwa für Linkwarden und Karakeep, Frigate oder Mealie. Docker und Podman lassen sich mit mehreren Hosts anbinden. Für Umsteiger wie mich praktisch: Homarr versteht auch die Docker-Labels von Homepage.

Wichtig für bestehende Installationen: Homarr 2.0 unterstützt nur noch SQLite und PostgreSQL, hier laufen die Migrationen beim Start automatisch. Wer bisher MySQL nutzt, muss seine Daten vor dem Update mit einem separaten Skript nach SQLite überführen. Die nötigen Schritte beschreibt eine Anleitung des Projekts.

Ob ich mein Homepage-Setup tatsächlich in Rente schicke, weiß ich noch nicht. Interessant wird Homarr 2.0 für mich aber ganz sicher. Die Live-Demo zum Reinschnuppern hilft euch gerade allerdings nicht weiter: Sie wird aktuell förmlich überrannt und ist daher offline. Welches Dashboard nutzt ihr in eurem Homelab?

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Die naheliegende Lösung: /etc/fstab plus ein Dispatcher-Skript für NetworkManager, das anhand von SSID oder Server-Erreichbarkeit automatisch mountet. Klingt nach einer Feierabend-Sache. Ist es aber nicht ganz – ich bin dabei über drei Stolperfallen gestolpert, die einem erst auffallen, wenn der Rechner runterfährt, aufwacht oder in den Standby soll. Genau die drei nehme ich hier mit euch durch.

Getestet habe ich das Ganze auf Arch Linux, aber das Setup ist nicht Arch-spezifisch: Solange eure Distribution systemd und NetworkManager mitbringt – also etwa auch Fedora, Ubuntu, Debian oder openSUSE –, funktioniert alles hier eins zu eins.

Der Grundaufbau

Netzwerkfreigaben bekommen in der fstab klassischerweise noauto, damit sie beim Boot nicht sofort, sondern erst bei Bedarf eingehängt werden:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0

Für den Mount-Typ selbst gibt’s je nach Protokoll gute Anleitungen im Arch Wiki, etwa zu Samba/CIFS und zu davfs2 für WebDAV – beide funktionieren unabhängig von der Distribution, solange cifs-utils beziehungsweise davfs2 installiert sind.

Das eigentliche Mounten übernimmt dann ein Skript unter /etc/NetworkManager/dispatcher.d/. NetworkManager ruft solche Skripte bei jeder Verbindungsänderung auf und übergibt Interface und Status (up, down, pre-down und ein paar weitere) mit – alle Details dazu stehen in der NetworkManager-dispatcher-Manpage. Ein simples Skript prüft die aktive WLAN-SSID und mountet, wenn’s passt:

#!/bin/bash
IFACE="$1"
STATUS="$2"

case "$STATUS" in
    up)
        SSID=$(nmcli -t -f active,ssid dev wifi | awk -F: '$1 == "yes" {print $2; exit}')
        if [[ "$SSID" == "MeinHeimnetz" ]]; then
            mount /mnt/server/home
            mount /mnt/server/data
        fi
        ;;
    down)
        umount /mnt/server/home
        umount /mnt/server/data
        ;;
esac

Fertig, oder? Nicht ganz. Sobald ihr das System runterfahrt, aus dem Standby weckt oder in den Standby schickt, zeigt sich, dass die Sache Tücken hat.

Warum nicht einfach GVfs?

Ihr fragt euch jetzt vielleicht, wieso ich mir das mit fstab und Dispatcher-Skripten überhaupt antue – GNOME bietet über „Mit Server verbinden“ im Dateimanager doch einen viel einfacheren Weg, Netzwerkfreigaben per SMB oder WebDAV einzubinden. Genau da liegt für mich das Problem.

Solche Mounts laufen nicht über den Kernel, sondern über GVfs, GNOMEs virtuelles Dateisystem. Programme, die die GIO-Bibliothek nutzen – fast alle GTK-Anwendungen, allen voran der Dateimanager selbst –, sprechen Freigaben direkt über eigene URIs wie smb:// oder dav:// an und zeigen entsprechend auch Vorschaubilder und Metadaten korrekt an. Für Programme, die das nicht können, blendet GVfs die Freigabe zusätzlich unter /run/user/<uid>/gvfs als ganz normalen Pfad ein. Diese Brücke läuft tatsächlich über FUSE – GVfs selbst ist zwar kein klassisches FUSE-Dateisystem, sondern eine eigene Architektur mit Daemon-Prozessen pro Protokoll, stellt aber genau für diesen Fall über gvfsd-fuse einen POSIX-kompatiblen Pfad bereit.

Genau diese Brücke ist bei mir der Knackpunkt: Nicht jedes Programm kommt damit zuverlässig klar. Konkret zeigt sich das bei mir in einem Markdown-Editor, in den ich auch Bilder für Artikel einbinde. Der Dateimanager zeigt die Bilder auf dem Netzlaufwerk ganz normal an, weil er GVfs nativ spricht. Der Markdown-Editor dagegen zeigt für dasselbe Bild nur einen Platzhalter – die Einbindung über den FUSE-Pfad funktioniert schlicht nicht zuverlässig, obwohl die Datei nachweislich da ist.

Ein klassischer Kernel-Mount über CIFS oder davfs2, wie im Rest dieses Artikels beschrieben, taucht dagegen als ganz normaler, stabiler POSIX-Pfad im Dateisystem auf – ohne Sonderbehandlung, für jedes Programm gleich. Der Mehraufwand mit fstab und Dispatcher-Skripten zahlt sich also gerade dann aus, wenn ihr Freigaben nicht nur im Dateimanager, sondern in ganz unterschiedlichen Anwendungen zuverlässig nutzen wollt.

Problem 1: Der Rechner fährt nicht mehr sauber runter

Fehlt in der fstab die Option _netdev, weiß systemd nicht, dass es sich hier um eine Netzwerkfreigabe handelt. Beim Shutdown kann es dann passieren, dass systemd versucht auszuhängen, nachdem das Netzwerk schon weg ist – der umount blockiert, bis der Job-Timeout greift, und euer System hängt beim Herunterfahren fest.

_netdev behebt das, weil systemd damit die richtige Reihenfolge kennt: erst aushängen, dann Netzwerk kappen. Wichtig ist außerdem, dass ein Dispatcher-Skript nicht nur auf down, sondern auf pre-down reagiert – der Status feuert, bevor die Verbindung wirklich fällt, während down schon danach kommt und für ein sauberes Aushängen zu spät ist. Damit das klappt, braucht es zusätzlich einen Symlink im Unterordner pre-down.d/.

Problem 2: Nach dem Aufwachen hängt sich der Dateimanager auf

Ein mount-Aufruf für CIFS oder WebDAV läuft im Kernel und kann bei nicht erreichbarem Server ziemlich lange blockieren – gerade kurz nach dem Aufwachen, wenn DNS oder Routing noch nicht ganz da sind. NetworkManager wartet standardmäßig synchron, bis so ein Dispatcher-Skript fertig ist, bevor es weitermacht. Hängt der mount-Aufruf, hängt bei euch plötzlich auch der Dateimanager oder die Netzwerkanzeige, weil die vom Verbindungsstatus abhängen.

Die Lösung: Mount-Versuche einfach im Hintergrund laufen lassen, damit das Dispatcher-Skript selbst sofort zurückkehrt, egal wie lange der eigentliche Mount braucht.

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

Problem 3: Der Standby funktioniert plötzlich nicht mehr

Und hier wird’s spannend. Mit der Lösung aus Problem 2 stolpert ihr in ein neues, deutlich fieseres Problem, das sich in meinem Fall so äußerte: Der Bildschirm geht aus, aber Tastaturbeleuchtung und LEDs bleiben an – ihr müsst hart abschalten. Was war passiert?

Der mount-Syscall für CIFS oder davfs blockiert bei nicht erreichbarem Server im sogenannten D-Zustand (uninterruptible sleep) – einem Zustand, den kein Signal unterbricht, auch SIGKILL nicht. Bevor der Kernel sich tatsächlich schlafen legt, versucht er, alle Prozesse einzufrieren. Ein Prozess im D-Zustand lässt sich aber nicht einfrieren, und der ganze Standby hängt fest, bis die Netzwerkoperation im Kernel von selbst aufgibt – das kann durchaus ein paar Minuten dauern.

Weil die Mount-Versuche aus Problem 2 jetzt länger im Hintergrund weiterlaufen, steigt eben auch die Chance, dass genau in dem Moment, in dem ihr in Standby gehen wollt, so ein blockierender Verbindungsversuch gerade aktiv ist.

Der zuverlässige Ausweg: Vor jedem mount erst mit einem echten Userspace-Verbindungstest prüfen, ob der Server überhaupt erreichbar ist – so einer lässt sich per Timeout wirklich abbrechen, zum Beispiel über Bashs eingebautes /dev/tcp:

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

Nur wenn der Test klappt, folgt der eigentliche mount. Damit landet ihr so gut wie nie mehr im riskanten, blockierenden Kernel-Connect, weil ihr zu dem Zeitpunkt schon wisst, dass der Server da ist.

Die Kombination, die bei mir funktioniert

Am Ende braucht ein robustes Setup vier Zutaten:

• _netdev in der fstab, damit systemd Netzwerkfreigaben beim Herunterfahren richtig einordnet.
• pre-down-Handling samt Symlink in pre-down.d/, damit das Aushängen garantiert vor dem Verbindungsabbau passiert – mit Timeout und Lazy-Unmount als Backup, falls der normale umount mal zickt.
• Asynchrone Mounts im up-Fall, damit NetworkManager und alles, was davon abhängt, nicht blockiert.
• Ein Erreichbarkeitstest vor jedem mount, damit der eigentliche, potenziell blockierende Kernel-Connect gar nicht erst passiert.

Dazu noch ein kleiner Healthcheck per systemd-Timer, der ein paar Minuten nach dem Boot und danach regelmäßig nachschaut, ob die Freigaben wirklich da sind, und notfalls nachhilft. Praktisch, falls der auslösende Netzwerk-Event mal zu früh oder zu spät kommt.

Alle Dateien im Überblick

Damit ihr das Ganze direkt nachbauen könnt, hier der komplette Satz an Dateien. Ich habe die Beispielnamen aus meinem eigenen Setup (ein Samba-Server namens bender, WebDAV via tuxedo) durch generische Platzhalter ersetzt – die müsst ihr natürlich an eure eigene Umgebung anpassen.

/etc/fstab – die beiden Freigaben, einmal Samba, einmal WebDAV:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
https://cloud.example.com/remote.php/dav/files/user /mnt/webdav davfs noauto,_netdev,uid=1000,gid=100,x-systemd.automount,x-systemd.idle-timeout=300,x-systemd.mount-timeout=15s 0 0

Die fstab referenziert die Zugangsdaten nur, gespeichert werden sie in eigenen Dateien – schon damit das Passwort nicht im Klartext in einer Datei steht, die jeder lesen kann.

/etc/samba/server.credentials – Zugangsdaten für die Samba-Freigabe:

username=maxmuster
password=GeheimesPasswort123

/etc/davfs2/secrets – Zugangsdaten für die WebDAV-Freigabe, referenziert wird hier der Mountpunkt statt einer Option in der fstab:

/mnt/webdav maxmuster GeheimesPasswort123

Beide Dateien gehören root und dürfen für niemand sonst lesbar sein:

$ sudo chmod 600 /etc/samba/server.credentials /etc/davfs2/secrets
$ sudo chown root:root /etc/samba/server.credentials /etc/davfs2/secrets

/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh – die gemeinsame Bibliothek, die alle anderen Skripte einbinden:

#!/bin/bash
log() {
    [[ "$DEBUG" == "1" ]] && logger -t "$LOG_TAG" -- "$1"
}

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

mount_with_retry() {
    local MOUNT="$1"
    local MAX_ATTEMPTS="${2:-3}"
    local SLEEP_SECONDS="${3:-2}"
    local MOUNT_TIMEOUT="${4:-10}"

    if mountpoint -q "$MOUNT"; then
        log "$MOUNT ist bereits eingehängt"
        return 0
    fi

    log "Hänge $MOUNT ein"

    local OUT ATTEMPT
    for ((ATTEMPT = 1; ATTEMPT <= MAX_ATTEMPTS; ATTEMPT++)); do
        if OUT=$(timeout "${MOUNT_TIMEOUT}s" mount "$MOUNT" 2>&1); then
            log "$MOUNT erfolgreich eingehängt"
            return 0
        fi
        log "Versuch $ATTEMPT/$MAX_ATTEMPTS für $MOUNT fehlgeschlagen (evtl. Timeout nach ${MOUNT_TIMEOUT}s): $OUT"
        [[ "$ATTEMPT" -lt "$MAX_ATTEMPTS" ]] && sleep "$SLEEP_SECONDS"
    done

    log "Alle Versuche für $MOUNT fehlgeschlagen"
    return 1
}

umount_with_fallback() {
    local MOUNT="$1"
    local TIMEOUT_SECONDS="${2:-5}"

    if ! mountpoint -q "$MOUNT"; then
        log "$MOUNT ist nicht eingehängt"
        return 0
    fi

    log "Hänge $MOUNT aus"

    if timeout "${TIMEOUT_SECONDS}s" umount "$MOUNT"; then
        log "$MOUNT erfolgreich ausgehängt"
        return 0
    fi

    log "Normaler Unmount von $MOUNT fehlgeschlagen, versuche Lazy Unmount"
    if umount -l "$MOUNT"; then
        log "$MOUNT per Lazy Unmount ausgehängt"
        return 0
    fi

    log "$MOUNT konnte nicht ausgehängt werden"
    return 1
}

/etc/NetworkManager/dispatcher.d/90-server-mount – Samba-Freigabe, gebunden an eine bestimmte WLAN-SSID oder ans Kabelnetz:

#!/bin/bash

DEBUG=1
LOG_TAG="server-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTS=(
    "/mnt/server/home"
    "/mnt/server/data"
)

mount_server() {
    if ! tcp_reachable server 445 2; then
        log "server auf Port 445 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    for MOUNT in "${MOUNTS[@]}"; do
        mount_with_retry "$MOUNT" 3 2 10
    done
}

umount_server() {
    for MOUNT in "${MOUNTS[@]}"; do
        umount_with_fallback "$MOUNT" 5
    done
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        if [[ "$IFACE" == wl* ]]; then
            SSID=$(nmcli -t -f active,ssid dev wifi |
                awk -F: '$1 == "yes" {print $2; exit}')

            log "Aktive WLAN-SSID: $SSID"

            if [[ "$SSID" == "MeinHeimnetz" ]]; then
                run_async mount_server
            fi

        elif [[ "$IFACE" == enp* || "$IFACE" == eth* ]]; then
            run_async mount_server
        fi
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mounts aushängen"
        umount_server
        ;;
esac

log "Dispatcher beendet"
exit 0

/etc/NetworkManager/dispatcher.d/90-webdav-mount – WebDAV-Freigabe, die einfach nur einen erreichbaren Cloud-Server voraussetzt:

#!/bin/bash

DEBUG=1
LOG_TAG="webdav-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTPOINT="/mnt/webdav"
HOST="cloud.example.com"

mount_webdav() {
    if ! tcp_reachable "$HOST" 443 3; then
        log "$HOST auf Port 443 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    mount_with_retry "$MOUNTPOINT" 3 2 10
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        run_async mount_webdav
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mount aushängen"
        umount_with_fallback "$MOUNTPOINT" 5
        ;;
esac

log "Dispatcher beendet"
exit 0

Für beide Skripte braucht ihr zusätzlich noch die passenden Symlinks, damit pre-down garantiert vor dem Verbindungsabbau feuert:

$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-server-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-server-mount
$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-webdav-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-webdav-mount

/usr/local/bin/mount-healthcheck.sh – das Sicherheitsnetz, das regelmäßig nachschaut:

#!/bin/bash
DEBUG=1
LOG_TAG="mount-healthcheck"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

log "Healthcheck gestartet"

SSID=$(nmcli -t -f active,ssid dev wifi 2>/dev/null |
    awk -F: '$1 == "yes" {print $2; exit}')

if [[ "$SSID" == "MeinHeimnetz" ]] || ping -c 1 -W 1 server >/dev/null 2>&1; then
    mount_with_retry "/mnt/server/home" 2 3
    mount_with_retry "/mnt/server/data" 2 3
else
    log "server im aktuellen Netz nicht erreichbar, überspringe"
fi

mount_with_retry "/mnt/webdav" 2 3

log "Healthcheck beendet"
exit 0

/etc/systemd/system/mount-healthcheck.service und mount-healthcheck.timer – Systemd-Einheiten, die das Healthcheck-Skript 60 Sekunden nach dem Boot und danach alle 10 Minuten anstoßen:

[Unit]
Description=Prueft und stellt Netzwerk-Mounts sicher
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
TimeoutStartSec=120
ExecStart=/usr/local/bin/mount-healthcheck.sh

[Unit]
Description=Fuehrt den Mount-Healthcheck 60s nach Boot und danach alle 10 Minuten aus

[Timer]
OnBootSec=60s
OnUnitActiveSec=10min
AccuracySec=30s

[Install]
WantedBy=timers.target

Aktivieren nicht vergessen:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now mount-healthcheck.timer

/usr/lib/systemd/system-sleep/90-cancel-network-mounts – optionales Sicherheitsnetz vor dem Suspend:

#!/bin/bash
case "$1/$2" in
    pre/*)
        logger -t sleep-mount-guard "Breche evtl. laufende Netzwerk-Mount-Versuche vor Suspend ab"
        pkill -9 -f 'mount.cifs' 2>/dev/null
        pkill -9 -f 'mount.davfs' 2>/dev/null
        ;;
esac

exit 0

Alle Skripte müssen ausführbar sein:

$ sudo chmod +x /etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh 
              /etc/NetworkManager/dispatcher.d/90-server-mount 
              /etc/NetworkManager/dispatcher.d/90-webdav-mount 
              /usr/local/bin/mount-healthcheck.sh 
              /usr/lib/systemd/system-sleep/90-cancel-network-mounts

Lange Rede, kurzer Sinn

Automatisches Einhängen von Netzwerkfreigaben über NetworkManager funktioniert gut, ist aber kein Fünf-Minuten-Job, wie es die Doku vermuten lässt. Wenn ihr nur den mount-Befehl in ein up-Skript packt, holt euch früher oder später eines der drei Probleme ein – meistens genau dann, wenn ihr unterwegs seid und kein Log zur Hand habt.

Mit _netdev, korrektem pre-down-Timing, asynchroner Ausführung und einem echten Erreichbarkeitstest vor jedem Mount seid ihr auf der sicheren Seite. Und das Muster lässt sich eins zu eins auf andere netzwerkabhängige Automatisierungen übertragen, etwa VPN-Verbindungen oder Backup-Jobs, die nur im richtigen Netz laufen sollen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

So bleibt der Zugriff auf das eigene Netzwerk auch dann möglich, wenn der Server eines Tages mal nicht so funktioniert, wie er soll. Wenn mit der Box generell etwas nicht stimmt und die Internetverbindung komplett wegbricht, ist in der Regel ohnehin alles verloren. Zudem sind Portweiterleitungen in diesem Fall ebenso wenig notwendig wie ein zusätzlicher DynDNS-Dienst, das übernimmt AVM mit seinem MyFritz-Service.

WireGuard auf der Fritzbox einrichten

Einrichten lässt sich das Ganze in der Fritzbox unter Internet » Freigaben im Reiter VPN (WireGuard). Dort wählt man Verbindung hinzufügen und anschließend Einzelgerät verbinden. Den Namen der Verbindung könnt ihr frei wählen, üblicherweise nutzt man hier den Namen des Client-Rechners oder der Person, die das VPN nutzen wird. Zum Schluss muss das Anlegen der Verbindung noch bestätigt werden, etwa per Telefon, Tastendruck oder über die Fritz-App.

Anschließend zeigt euch die Fritzbox eine Seite mit einem QR-Code. Den könnt ihr zum Beispiel mit dem Smartphone scannen, um die Verbindung direkt in die offizielle WireGuard App für Android zu übernehmen. Alternativ geht auch die Open-Source-App WG Tunnel, die deutlich mehr Funktionen bietet als der „offizielle“ WireGuard-Client für Android. Ich persönlich nutze WG Tunnel, das ich über F-Droid installiert habe.

WireGuard-Konfiguration in NetworkManager

Für Linux (und generell Desktop-PCs) bietet die Fritzbox die Möglichkeit, die Konfiguration herunterzuladen. Klickt auf den Button und speichert die Datei lokal auf der Festplatte ab. Die Datei wird standardmäßig als wg_config.conf im Ordner Downloads gespeichert. Der Name ist nicht ganz unwichtig, da einige WireGuard-Clients diesen Namen automatisch zur Benennung der Schnittstelle heranziehen.

Den Import erledigt ihr direkt über den NetworkManager am Desktop oder per Kommandozeile. Unter GNOME geht ihr in die Einstellungen, dann Netzwerk, dort klickt ihr auf das Plus-Symbol und wählt Aus Datei importieren …. Danach die Datei wg_config.conf auswählen und importieren. Den Namen der Verbindung könnt ihr dann in den Einstellungen beliebig anpassen, ich empfehle aber, den Schnittstellennamen auf wg0 zu setzen.

$ nmcli connection import type wireguard file ~/Downloads/wg_config.conf
Verbindung »wg_config« (39724859-b102-4446-bdb2-1ec60f501360) erfolgreich hinzugefügt.

Das war es schon. Ihr könnt das VPN jetzt direkt über die Quick Settings in GNOME aktivieren. Auch andere Desktopumgebungen wie KDE bieten passende Möglichkeiten. Wenn ihr prüfen möchtet, ob die Verbindung steht, installiert unter GNOME die Erweiterung IP Finder. Sie zeigt euch die öffentliche IP-Adresse mitsamt Länderflagge. Sobald dort die Flagge eures Wohnorts erscheint statt eures aktuellen Aufenthaltsorts (bspw. im Urlaub im Ausland), steht das VPN.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Eine Zeit lang habe ich stattdessen Omnivore ausprobiert, was einen offenen Ansatz verfolgte und auch mit einem Linux-Desktop gut zusammenspielte. Doch auch dieser Dienst wurde inzwischen eingestellt. Heute setze ich auf eine selbstgehostete Lösung: Wallabag. Die Anwendung lässt sich auf dem eigenen Server betreiben, unterstützt zahlreiche Importformate und bringt Apps und Erweiterungen für verschiedene Plattformen mit.

Dass Mozilla Pocket nun endgültig einstellt, überrascht mich also nicht persönlich. Betroffen macht es trotzdem, denn für viele war der Dienst ein zuverlässiger Begleiter im digitalen Alltag.

Am 8. Juli 2025 ist Schluss

Wie Mozilla mitteilt, wird der Dienst zum 8. Juli 2025 offiziell abgeschaltet. Bis dahin bleibt Pocket noch wie gewohnt nutzbar, per App, Browser-Erweiterung oder Weboberfläche. Ab diesem Datum wechselt der Dienst in einen sogenannten „Export-Only-Modus“: Ihr könnt eure gespeicherten Inhalte weiterhin exportieren, aber nicht mehr nutzen oder neue Inhalte hinzufügen.

Wichtig: Die Frist zum Export läuft am 8. Oktober 2025 ab. Danach werden sämtliche Nutzerkonten und gespeicherte Daten gelöscht – unwiderruflich. Eine Anleitung gibt detaillierte Informationen, wie man seine gespeicherten Daten exportieren kann.

Mozillas Begründung zum Ende

Offiziell heißt es, das Nutzungsverhalten im Netz habe sich verändert. Mozilla wolle sich auf Projekte konzentrieren, die „besser zu den heutigen Surfgewohnheiten“ passen. Im Hintergrund dürfte aber vor allem eines eine Rolle spielen: Ressourcen.

Seit der Übernahme im Jahr 2017 hatte Mozilla Pocket zwar technisch weiterentwickelt und in Firefox eingebunden, zuletzt aber immer weniger Aufmerksamkeit darauf gelenkt. Die automatische Integration in den „Neuer Tab“-Bildschirm von Firefox zeigte bereits, dass Pocket zunehmend als Content-Empfehlungsmaschine und nicht mehr als Lesezeichen-Dienst verstanden wurde.

Mit dem Aus für Pocket will Mozilla diese Empfehlungssparte nun über andere Kanäle fortführen: Im Firefox-Startbildschirm, per Newsletter („Ten Tabs“) und über redaktionell kuratierte Inhalte. Ich hoffe mal stark, dass man in Firefox alle diese Inhalte weiterhin deaktivieren kann. Ich für meinen Teil will beim Öffnen eines Tabs nichts anderes sehen als eine weiße Fläche. Schon allein eine kurze Bedenkzeit zum Laden dieser Inhalte bremst beim Arbeiten aus.

Wie ihr eure Daten rettet

Wenn ihr Pocket genutzt habt, solltet ihr nicht bis Juli warten, sondern eure Inhalte möglichst bald sichern. Der Export enthält: Eure Leseliste, die archivierten Artikel, Favoriten und die Notizen und Markierungen. Die Daten lassen sich als HTML-Datei exportieren, die sich lokal speichern und mit anderen Diensten weiterverarbeiten lässt. Eine direkte Migration zu Alternativen ist zwar nicht vorgesehen, aber manche Drittanbieter bieten zumindest Importfunktionen für Pocket-Exporte an. Bei Wallabag läuft der Import über die Pocket API.

Was passiert mit Pocket Premium?

Wer ein kostenpflichtiges Pocket-Premium-Abo abgeschlossen hat, erhält eine anteilige Rückerstattung. Die Regeln sind dabei klar:

• Monatsabos: Die automatische Verlängerung wird sofort gestoppt. Es fallen keine weiteren Kosten an, Rückerstattungen sind nicht vorgesehen.
• Jahresabos: Die Abonnements werden am 8. Juli 2025 gekündigt. Der ungenutzte Zeitraum wird automatisch auf das ursprüngliche Zahlungsmittel zurückerstattet.

Ein manuelles Eingreifen ist in beiden Fällen nicht nötig. Ich glaube aber, dass hier kaum jemand für Pocket gezahlt haben dürfte.

Erweiterungen und Apps: Was bleibt, was verschwindet?

Ab dem 22. Mai 2025 wird die Pocket-Erweiterung nicht mehr über die offiziellen Browser-Add-on-Seiten angeboten. Bereits installierte Erweiterungen bleiben zunächst bestehen, funktionieren aber nur bis zum 8. Juli. Danach verweisen sie lediglich noch auf die Export-Seite. Entfernen müsst ihr die Erweiterungen dann selbst – eine automatische Deinstallation erfolgt nicht.

Auch die Pocket-App für Android- oder Apple-Smartphones und Tablets verschwindet nach dem 22. Mai aus den App Stores. Wer sie bereits installiert hat, kann sie noch bis zum 8. Oktober neu installieren. Auch wenn sie nicht automatisch vom Handy verschwindet. Nach dem offiziellen Ende ist auch hier Schluss. Ein Grund mehr, sich nach Alternativen umzusehen.

Alternativen: Wohin jetzt?

Das Ende von Pocket reißt eine Lücke – gerade für all jene unter euch, die plattformübergreifend lesen, speichern und sortieren möchten, ohne sich auf datenhungrige Konzerne verlassen zu müssen. Es gibt Alternativen, die teilweise freie Software sind und mehr Kontrolle bieten:

• Wallabag: Eine selbst hostbare, freie Pocket-Alternative. Unterstützt Importe, Tags, Offline-Lesen und hat Apps für Android & iOS.
• Linkding: Ein minimalistischer Self-Hoster für Lesezeichen, nicht speziell für „Read-it-later“, aber flexibel erweiterbar.
• Shiori: Einfache, self-hostbare Lesezeichenverwaltung mit Read-it-later-Funktion und Webinterface.
• Karakeep (ehemals Hoarder): Moderner „Read-it-later“-Dienst mit Markdown-Unterstützung und Webclipper-Erweiterung.

Diese Lösungen setzen teils einen eigenen Server voraus, was Aufwand bedeutet, aber auch mehr Kontrolle über eure Daten. Ich bin es mittlerweile leid, solche Dienste alle naselang zu migrieren. Neben Feedreadern hoste ich auch meinen Read-It-Later-Dienst lieber selber. Eine Liste mit weiteren Alternativen findet ihr bei selfh.st.

Fazit: Ein leiser Abschied mit großem Echo

Die Einstellung von Pocket ist mehr als nur das Ende eines Produkts. Sie erinnert uns daran, wie schnell selbst langjährig genutzte Dienste verschwinden können, selbst wenn sie von gemeinnützigen Organisationen betrieben werden. Ich habe Pocket zwar nicht selber genutzt, ich kann mir aber gut vorstellen, dass es Mozilla-User gibt, die dem Dienst nachtrauern werden.

Die wichtigste Lehre daraus sollte sein: Setzt euch mit Selfhosting auseinander. Wer Dienste selbst betreibt, hat mehr Kontrolle über Funktionen, Daten und Zukunftssicherheit und spart auf lange Sicht oft sogar Zeit und Geld. Die freie Software-Welt bietet für praktisch jeden proprietären Dienst eine leistungsfähige Open-Source-Alternative. Nutzt sie!

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Auf dem Smartphone nutze ich je nach Laune die ambitioniert entwickelte und bis ins kleinste Detail konfigurierbare, dafür aber proprietäre App Symfonium oder die Open-Source-App Tempo. Beide integrieren sich via Android Auto in das Display geeigneter Fahrzeuge. Bei Tempo muss man allerdings wissen, wie. Denn als Open-Source-App steht Google als Gatekeeper im Weg.

Warum Navidrome?

Navidrome ist ein freier Musikserver, der über das Subsonic-Protokoll funktioniert. Er läuft ressourcenschonend (bei mir in einem Docker-Container) und kommt mit einem relativ modernen Web-Interface, einer umfangreichen API und Support für zahlreiche Clients für alle gängigen Betriebssysteme. Natürlich auch für Linux und Android. Der große Vorteil: Ich habe jederzeit und überall Zugriff auf meine eigene Musik, ohne dass ich Drittanbieter bezahlen oder Werbung konsumieren muss.

• Läuft auf nahezu allem: Raspberry Pi, NAS, Server
• Standardisierte Schnittstelle: Kompatibel zu vielen Subsonic-Clients
• Unterstützt mehrere Benutzer: Praktisch, wenn ihr eure Sammlung mit Familie oder WG teilt
• Transcoding: Wer mag, kann die Musik je nach Verbindung automatisch herunterrechnen lassen

Für mich ist Navidrome die ideale Lösung, weil ich meine Musik selbst tagge und verwalte, ohne dass eine Plattform mir „ähnliche Künstler“ aufdrängen oder meine Playlisten analysieren muss. Und ja, wir kommen ja alle mal in ein Alter, in dem man nicht mehr tagtäglich ein neues Album oder neue Künstler in der eigenen Musiksammlung willkommen heißt und sich daher ein Account bei Spotify und Co. auf jeden Fall lohnt. #leiderwahr

Tempo: Schlichter Client mit klarer Linie

Tempo ist eine native Android-App, die sich gezielt an Nutzer von Subsonic-kompatiblen Servern richtet. Playback lokal gespeicherter Musik gibt es beispielsweise nicht. Im Gegensatz zu überladenen Playern setzt Tempo auf Klarheit und Geschwindigkeit. Die App ist quelloffen, werbefrei und lässt sich unkompliziert via F-Droid oder GitHub installieren.

Ich, wie auch die Entwickler, empfehle allerdings die Installation der GitHub-Version über die APK-Datei, da nur sie alle Funktionen beinhaltet. Zudem hinkt die F-Droid-Version schon seit einiger Zeit hinterher. Auf der GitHub-Seite steht daher auch: „Use the GitHub version of the app for full Android Auto and Chromecast support.“

Für Symfonium muss man hingegen nach einer kurzen Testphase eine lebenslang gültige Lizenz erwerben. Mit einer mindestens 7 Euro großen Spende kostet diese allerdings nicht die Welt. Zudem kümmert sich der Entwickler regelmäßig um seine App. Das Changelog der zuverlässig eintrudelnden Updates ist meist zu lang zum Lesen.

Funktionen

• Übersichtliche Navigation nach Künstlern, Alben, Genres oder Jahrzehnten
• Gapless Playback für nahtloses Hören (wichtig bei Live-Alben)
• Playlist-Verwaltung direkt in der App
• Unterstützung von Last.fm-Scrobbling
• Chromecast-Integration
• Android Auto-Support

Android Auto mit Tempo nutzen

Damit Tempo im Auto funktioniert, muss Android Auto nicht nur auf dem Smartphone installiert sein, sondern auch bestimmte Einstellungen freigegeben werden. Gerade bei Apps, die wie Tempo nicht über Googles Play Store kommen, ist das etwas versteckt.

Entwicklermodus für Android Auto aktivieren

Zuerst müsst ihr den Entwicklermodus von Android Auto aktivieren, damit Tempo als App auf dem Display im Auto erscheint. Geht dazu auf eurem Handy in die Android-Auto-Einstellungen:

• Android 10 oder neuer: Einstellungen » Apps » Alle X Apps ansehen » Android Auto » Zusätzliche Einstellungen in der App
• Android 9 oder älter: Direkt in der Android-Auto-App unter Menü » Einstellungen

Scrollt dort ganz nach unten und tippt zehnmal auf die Versionsnummer. Ähnliches kennt man ja vom Entwicklermodus von Android selbst. Danach erscheint die Frage, ob ihr die Entwickleroptionen aktivieren wollt. Bestätigt mit OK. Öffnet danach das Dreipunkt-Menü oben rechts und wählt dort Entwicklereinstellungen.

Aktiviert in diesem Dialog nun die Option Unbekannte Quellen. Damit erlaubt ihr auch alternativen Apps wie eben Tempo den Zugriff auf Android Auto. Auch ohne dass die Entwickler eine offizielle Play-Store-Zertifizierung erworben haben, was für Open-Source-Projekte nicht ganz so einfach wäre.

Hinweis: Die Aktivierung müsst ihr nur einmal durchführen. Danach wird Tempo automatisch als Medien-App erkannt, sobald euer Smartphone per Kabel oder kabellos mit dem Auto verbunden ist.

Tempo auf dem Smartphone installieren

Da Tempo aktuell nicht im Google Play Store zu finden ist, installiert ihr die App manuell: Über F-Droid, andere Open-Source-Market-Clients wie Droid-ify oder direkt via GitHub-Releases. Achtet darauf, dass in den Android-Einstellungen die Installation aus unbekannten Quellen für den jeweiligen Browser oder Dateimanager erlaubt ist.

Hinweis: Wie oben bereits erwähnt, benötigt ihr die GitHub-Version (aktuell Tempo 3.9.0), wenn ihr Android Auto verwenden wollt. Mit Tempo 3.8.1 via F-Droid erscheint Tempo zwar auch unter den Android-Auto-Apps, beim Start erscheint allerdings nur ein leerer Bildschirm. Hier ist der entsprechende Bug dazu.

Nach dem ersten Start gebt ihr die URL eures Subsonic-Servers, Benutzernamen und Passwort an. Tempo verbindet sich dann direkt mit eurer Sammlung. Selbstverständlich unterstützt Tempo auch andere Server, die das Subsonic-Protokoll nutzen. Ich für meinen Teil habe die App zusammen mit meinem Navidrome-Server ausprobiert, was ohne Probleme funktioniert.

Optional: Transcoding in Tempo aktivieren

Tempo unterstützt (wenn euer Server das erlaubt) auch Transcoding. Gerade im Auto kann es sinnvoll sein, FLACs oder hochauflösende Formate als MP3 mit 192 oder 256 kbit/s zu streamen. Das spart (zumindest bei mir) begrenztes Datenvolumen und läuft auch bei wackliger Verbindung stabil. Die entsprechenden Einstellungen findet ihr in den Settings von Tempo. In meinem Fall musste ich innerhalb von Navidrome das Transcoding nicht gesondert konfigurieren.

Mit Tempo auf dem Handy und im Auto

Mit Navidrome und Tempo gibt es eine komplett freie Lösung für die mobile Musiknutzung unter Android, inklusive Integration ins Auto via Android Auto. Man ist komplett unabhängig von Streamingdiensten, kann seine eigene Musik in hoher Qualität hören und umgeht vollständig Tracking, Werbung oder Abozwang.

Gerade wer seine Sammlung über Jahre gepflegt hat und Wert auf Datenschutz legt, findet hier eine schlanke, respektvolle Alternative zur Cloud. Und das Beste: Tempo macht auf dem Auto-Display eine richtig gute Figur: Schlicht, funktional und auf das Wesentliche reduziert.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Trotz aller Tipps aus der AVM-Wissensdatenbank und unzähliger Anpassungen in den Einstellungen änderte sich daran nichts. Ich vermute ein thermisches Problem: Nach Abschalten und einer Abkühlphase funktioniert das WLAN zunächst stabil, doch je länger die Fritzbox wieder in Betrieb war, desto häufiger traten die Aussetzer erneut auf.

Warum die Wahl auf die Fritzbox 5690 Pro fiel

Ein kompletter Neustart war also nötig. Allzu sehr hat mich das nicht gestört – die 7580 war ohnehin ein eher enttäuschendes Modell. Zwar ursprünglich von AVM als Flaggschiff gedacht, blieb sie in Sachen Software-Updates und Funktionen schnell auf der Strecke. WireGuard als moderne VPN-Lösung wurde zum Beispiel nie integriert. Das war für mich ein echter Minuspunkt, da ich mir nach der Ankündigung seitens AVM einen wesentlich vereinfachten und verbesserten VPN-Zugang zur Fritzbox von Linux-Systemen aus versprochen hatte.

Da bei mir – eventuell – in unbestimmter Zukunft ein Wechsel auf Glasfaser ansteht, fiel die Wahl auf die AVM Fritzbox 5690 Pro. Der Router ist für DSL und Glasfaser ausgelegt und somit bestens geeignet für den Übergang. Wer wie ich aktuell noch DSL nutzt, aber mittelfristig auf Glasfaser umsteigen will, muss so nicht erneut Geld in die Hand nehmen. Preislich liegt die neue Fritzbox bei rund 300 Euro – kein Schnäppchen, aber dank der Dual-Modem-Ausstattung irgendwie noch zu vertreten.

Reibungsloser Umzug von alter zu neuer Fritzbox

Der Wechsel verlief erstaunlich problemlos. Die Export- und Importfunktion der Fritzbox hat zuverlässig funktioniert: Zugangsdaten für den DSL-Anschluss wurden korrekt übernommen, ebenso meine Netzwerkkonfiguration. In meinem Netzwerk läuft ein Pi-hole zur netzweiten Werbeblockade – das funktionierte sofort wieder wie gewohnt. Auch DynDNS, Portweiterleitungen und das über Google synchronisierte Telefonbuch wurden korrekt übertragen.

Nur bei den DECT-Geräten wie dem Fritzfon C6 (nutze ich eigentlich nur noch zum Bestätigen von Einstellungen in der Fritzbox – meine Festnetznummer kennen und nutzen noch genau zwei Personen) sowie bei den Smart-Home-Komponenten wie Steckdosen und Heizkörperthermostaten musste ich einmal manuell Hand anlegen. Die Geräte ließen sich jedoch schnell wieder neu verbinden. Gruppen und Schaltpläne blieben erhalten, sodass der Aufwand minimal war.

Was die 5690 Pro kann – und was (noch) nicht

Technisch bietet die 5690 Pro vieles, was man aktuell erwarten darf. Mit Wi-Fi 7, Zigbee und DECT-ULE ist die Ausstattung zukunftssicher. Vor allem Zigbee ist interessant für alle, die smarte Geräte unterschiedlicher Hersteller direkt über die Fritzbox steuern wollen. Ich habe derzeit noch keine Zigbee-Hardware im Einsatz, bin aber gespannt, wie gut das Zusammenspiel in der Praxis funktioniert.

Etwas ernüchternd ist allerdings die Situation rund um den Smart-Home-Standard Matter. AVM hatte Matter-Support für die FRITZ!Box 5690 Pro angekündigt, doch bislang ist davon rein gar nichts zu sehen. Auf der Produktseite fehlt inzwischen sogar jede Erwähnung von Matter, und wer sich informieren will, muss sich durch ältere Pressemitteilungen klicken – zum Beispiel die von AVM zur ANGA COM 2024:

Fritzbox 5690 Pro: Triband-Fritzbox für Fiber und DSL mit Wi-Fi 7 und Zigbee … Dank der Unterstützung von Zigbee, DECT ULE und zukünftig auch Matter können zusätzlich zu den smarten FRITZ!-Produkten viele Geräte anderer Hersteller integriert werden. – AVM, 13.05.2024

Support für Matter? Großes Fragezeichen

Wer schon jetzt Matter mit AVM-Geräten in sein Smart Home einbinden möchte, ist auf das zusätzliche FRITZ!Smart Gateway angewiesen. Das kommt für mich aktuell nicht infrage – die nötige Hardware steckt ja bereits in der 5690 Pro. Es wäre wünschenswert, wenn AVM hier bald nachliefert. Irgendwie habe ich allerdings Zweifel daran: Die 5690 Pro war ewig angekündigt, aber lange nicht im Handel erhältlich. Irgendwie ist da der Wurm drin.

Ein weiteres Fragezeichen steht hinter den Labor-Firmwares. AVM hatte zwischenzeitlich eine Labor-Version für die 5690 Pro veröffentlicht, aktuell gibt es jedoch keine neue Testversion. Offenbar wurde das Programm mit dem offiziellen Release von FRITZ!OS 8.0 eingestellt. Wer also gerne neue Funktionen ausprobiert, muss sich bei den Boxen der 7x90er-Reihe umsehen. Finde ich persönlich schade, da ich aus persönlichem und beruflichem Interesse ganz gerne die Labor-Firmwares austeste.

Fazit nach den ersten Tagen

Die Fritzbox 5690 Pro läuft bei mir bisher stabil und zuverlässig. Der Umzug verlief erstaunlich einfach, die Konfiguration war schnell wieder einsatzbereit. Dass sich die Box für DSL und Glasfaser gleichermaßen eignet, macht sie besonders flexibel. Im Paket liegen zwei SFP-Module für AON- und GPON-Glasfaseranschlüsse. Die aktuellen Standards werden also unterstützt, doch wie immer: Nach dem Standard kommt der nächste Standard.

Wi-Fi 7 ist vorhanden, und neue Smartphones verbinden sich auch darüber. In der Praxis ist bei mir die Datenrate via WLAN allerdings gar nicht so viel höher, da ja oft durch Wände hindurch gefunkt werden muss. Da ist dann bei den hohen Frequenzen von Wi-Fi 7 schnell Schluss mit sehr hohem Datendurchsatz. Der integrierte Switch unterstützt immerhin Gigabit-Ethernet und über den kombinierten LAN-/WAN-Port einmal 2,5-Gigabit. Der USB-Anschluss arbeitet mit USB 3.1. Wer einfach nur eine externe USB-Festplatte ins Netz stellen möchte, ist damit vermutlich sogar happy.

Es gibt allerdings noch Baustellen: Die Unterstützung für Matter fehlt bislang, und experimentierfreudige Nutzer müssen auf Labor-Updates verzichten. Trotzdem bin ich unterm Strich zufrieden. Die 5690 Pro macht einen soliden Eindruck – auch wenn AVM bei Smart-Home-Standards gern etwas schneller vorankommen dürfte. Erst mit Matter wird die Box allerdings so richtig komplett. Dann lässt sich die Fritzbox auch wieder in Google Home einbinden. Etwas, das ich seit dem Ende von FRITZ! Smart Home in Alexa und Google Home wirklich vermisse.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Installation von dockcheck

Dockcheck benötigt lediglich eine laufende Docker-Installation inklusive Docker Compose (als Plugin oder standalone) sowie einige kleinere Abhängigkeiten wie jq und regclient/regctl. Fehlende Pakete installiert das Skript bei Bedarf selbst oder gibt Hinweise dazu aus.

Die Installation ist denkbar einfach:

$ curl -L https://raw.githubusercontent.com/mag37/dockcheck/main/dockcheck.sh -o ~/.local/bin/dockcheck.sh
$ chmod +x ~/.local/bin/dockcheck.sh

Anschließend könnt ihr das Skript direkt aufrufen:

$ dockcheck.sh -h

Info: Dazu muss der Ordner ~/.local/bin natürlich in der $PATH-Variable enthalten sein. Ergänzt bei Bedarf die Pfadangabe in eurer ~/.bashrc oder einer anderen passenden Konfigurationsdatei.

Nutzung von dockcheck

Dockcheck überprüft die installierten Container-Images und aktualisiert sie bei Bedarf. Mit der Option -x nutzt Dockcheck mehrere Prozesse, was die Geschwindigkeit ganz wesentlich erhöht. Ein einfaches Update aller Container sieht so aus:

### Mit Informationen und Nachfragen:
$ dockcheck.sh -x 5

### Alle Container automatisiert aktualisieren:
$ dockcheck.sh -y -p -x 5

Dabei bewirken die Parameter:

• -y: Automatische Updates ohne Rückfragen.
• -p: Bereinigt alte, nicht mehr genutzte Images nach dem Update.
• -x N: Parallele Update-Prozesse (Standard: 1, kann für schnellere Updates erhöht werden).

Möchtet ihr bestimmte Container ausschließen, könnt ihr die Option -e nutzen. Das ist praktisch, wenn bei einem wichtigen Projekt größere Updates anstehen oder ein Container einfach nie aktualisiert werden soll.

$ dockcheck.sh -x 5 -e nextcloud,withings-gc-bridge
Excluding these names:
nextcloud
withings-gc-bridge

[##################################################] 31/31 

Containers on latest version:
authelia
changedetection-playwright-chrome-1
...
wallabag-wallabag-1

Containers with updates available:
1) changedetection
2) immich_server

Choose what containers to update.
Enter number(s) separated by comma, [a] for all - [q] to quit: 

Weitere praktische Optionen sind:

• -d N: Nur Images aktualisieren, die mindestens N Tage alt sind.
• -s: Auch gestoppte Container prüfen.

Updates im Blick behalten

Dockcheck macht das Aktualisieren von Docker-Containern sehr einfach – vielleicht aber fast schon zu einfach. Das Skript installiert neue Container-Images ohne weitere Prüfung. Falls ein Update zu Problemen führt oder manuelle Anpassungen erfordert, bekommt ihr das nicht direkt mit. Daher empfiehlt es sich, News-Quellen wie This Week in Self-Hosted im Auge zu behalten, um über Änderungen informiert zu bleiben und Dockcheck nicht einfach jeden Tag blind anzuwerfen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.