Doch was ist eigentlich der beste Weg? Gibt es Vor- und Nachteile, wenn man die Fritzbox-Freigaben über den Dateimanager einbindet? Wie sieht es mit der Datei /etc/fstab oder mit systemd aus? Und was ist mit FTP: Arbeitet das fast schon in Vergessenheit geratene Protokoll schneller? Eine Messreihe auf zwei Systemen liefert die Antworten.

Bevor es um Linux-Werkzeuge geht: Die Freigaben der Fritzbox lassen sich auch im Browser öffnen, unter https://fritz.box/nas#/. Dort zeigt die Weboberfläche FritzNAS nach der Anmeldung dieselben Ordner, die später im Dateimanager auftauchen, samt Ordner des USB-Sticks. Über Hinzufügen und Neuer Ordner lassen sich Dateien hochladen und Ordner anlegen, eine Suche gibt es ebenfalls. Für einzelne Dateien genügt das, für den Alltag sind die Wege weiter unten bequemer.

Was ihr vorher in der Fritzbox einstellt

Ohne Benutzer geht erst einmal nichts, denn die Fritzbox lässt Gäste nicht an den Speicher. Der Zugriff über das Netz ist immer an ein Konto gebunden. Legt daher unter System | FRITZ!Box-Benutzer einen eigenen Benutzer für den Linux-Rechner an und gebt ihm die Berechtigung Zugang zu NAS-Inhalten, mit Vollzugriff, wenn ihr auch schreiben wollt. Einen Link dorthin findet ihr auch in den Speichereinstellungen unter Benutzer verwalten.

Die Dienste schaltet ihr unter Heimnetz | USB / Speicher | Heimnetzfreigabe ein. Dort braucht ihr das Häkchen bei Zugriff über ein Netzlaufwerk (SMB). Der Freigabename steht ab Werk auf FRITZ.NAS und die Arbeitsgruppe auf WORKGROUP. Unterstützung für SMBv1 bleibt aus, die braucht ihr nicht. Wollt ihr auch FTP nutzen, setzt ihr das Häkchen bei Zugriff über FTP. In der Geräteübersicht muss außerdem NAS-Speicher-Funktion auf Aktiv stehen.

Erreichbar ist die Freigabe unter fritz.box. Sie nutzt SMB, das Protokoll, das auch Windows für Netzlaufwerke verwendet, AVM nennt die Versionen 2 und 3. Darunter liegen die Ordner des Speichers, ein angesteckter USB-Stick erscheint als eigener Unterordner. Der Name fritz.box gilt nur im Heimnetz. Die Oberfläche nennt dort auch die IP-Adresse der Box, die ihr statt des Namens verwenden könnt, falls fritz.box einmal nicht gefunden wird.

Ob es geklappt hat, seht ihr in der Geräteübersicht: Der Stick steht dort als USB-Speicher, darunter der Hinweis USB 3.0. Bei der Fritzbox 5690 Pro war der Stromsparmodus ab Werk aktiv, der Stick lief dadurch gebremst. Der Unterschied ist spürbar, denn im Stromsparmodus liefert der Anschluss nur das Tempo von USB 2.0.

GNOME: Dateien

Bei Ubuntu mit GNOME braucht ihr nichts nachzuinstallieren, die nötige Unterstützung für Netzfreigaben ist an Bord. Sie heißt GVfs und ist die Schicht, über die Nautilus auf Netzfreigaben zugreift. Öffnet Dateien, drückt Strg+L und tippt smb://fritz.box in die Adresszeile. Ob die Box in der Netzwerkansicht auftaucht, spielt dabei keine Rolle, die direkte Adresse genügt.

Nautilus zeigt unter Windows-Speicher auf fritz.box zuerst nur den Eintrag FRITZ.NAS, ein Passwort will es dafür noch nicht. Erst der Doppelklick darauf öffnet den Anmeldedialog. Dort schaltet ihr bei Verbinden als auf Registrierter Benutzer, tragt den Fritzbox-Benutzer samt Passwort ein und lasst die Domäne bei WORKGROUP. Wählt ihr Nie vergessen, speichert GNOME das Passwort im Schlüsselbund, und der Dialog bleibt künftig weg.

Danach zeigt Nautilus die Ordner der Freigabe, und links in der Seitenleiste steht ein Eintrag für fritz.nas auf fritz.box, über den ihr sie jederzeit wieder öffnet. Das Auswurfsymbol daneben trennt die Verbindung. Der angesteckte USB-Stick erscheint als eigener Ordner, er trägt den Namen des Datenträgers. Dateien lassen sich dort wie in jedem anderen Ordner kopieren, verschieben und löschen.

Auch Programme, die nichts von GNOME wissen, kommen an die Dateien. GNOME blendet die Freigabe zusätzlich als normalen Ordner unter /run/user/1000/gvfs/smb-share:server=fritz.box,share=fritz.nas ein, dort funktionieren ls, cp oder dd ganz normal. Das hilft bei Skripten. Der Pfad enthält die Benutzerkennung und existiert nur, solange die Freigabe verbunden ist. Auf der Kommandozeile hängt gio mount die Freigabe ohne Dateimanager ein:

$ gio mount smb://fritz.box/FRITZ.NAS

KDE Plasma: Dolphin

Unter TUXEDO OS mit Plasma tippt ihr in Dolphin Strg+L, dann smb://fritz.box/ in die Adresszeile und bestätigt mit Enter. Anders als Nautilus fragt Dolphin sofort nach Benutzer und Passwort, noch bevor es etwas anzeigt. Tragt den Fritzbox-Benutzer ein und setzt, wenn ihr den Dialog nicht jedes Mal sehen wollt, das Häkchen bei Passwort merken.

Beim Öffnen der Freigabe fragt Dolphin ein zweites Mal, diesmal für FRITZ.NAS selbst (Server fritz.box, Ressource FRITZ.NAS). Die Felder sind dann schon ausgefüllt, ihr bestätigt nur noch mit OK. Danach zeigt Dolphin die Ordner der Freigabe, der USB-Stick erscheint wieder als eigener Ordner. Lesen und das Anlegen eines Ordners funktionierten im Test.

Andere Programme sehen die Freigabe nicht ohne Weiteres: Dolphin nutzt dafür die KDE-eigene Schicht KIO, die nur KDE-Programme verstehen. Ein Zusatzdienst namens kio-fuse würde die Freigabe für alle Programme als Ordner einblenden, im Test verweigerte er aber jeden Zugriff. Dolphin selbst konnte schreiben. Wer feste Pfade braucht, die jedes Programm versteht, ist mit der /etc/fstab besser bedient.

Dauerhaft: die Freigabe in der /etc/fstab

Die Datei /etc/fstab legt fest, welche Laufwerke Linux einbindet. Tragt ihr die Freigabe dort ein, bekommt ihr einen gewöhnlichen Ordner, etwa /mnt/fritz. Das lohnt sich vor allem für Programme, die nur normale Pfade kennen, und für Skripte ohne Anmeldedialog. Dafür braucht ihr das Paket cifs-utils (bei Ubuntu meist schon installiert). Die Zugangsdaten gehören nicht in die fstab, sondern in eine eigene Datei, die nur root lesen darf:

$ sudo install -m 600 /dev/null /etc/fritz-smb.cred
$ sudo nano /etc/fritz-smb.cred

username=DEIN_FRITZBOX_BENUTZER
password=DEIN_PASSWORT

Danach legt ihr den Ordner an, in dem die Freigabe erscheinen soll (den Mountpunkt), und ergänzt die fstab um eine Zeile. Sie nennt Quelle, Mountpunkt, Dateisystemtyp und Optionen, die beiden Nullen am Ende bleiben bei Netzfreigaben immer so. Die Optionen x-systemd.automount und noauto sorgen dafür, dass die Freigabe erst beim ersten Zugriff eingehängt wird. So wartet der Rechner beim Start oder im fremden WLAN nicht auf die Fritzbox:

$ sudo mkdir -p /mnt/fritz
$ sudo nano /etc/fstab

//fritz.box/FRITZ.NAS  /mnt/fritz  cifs  credentials=/etc/fritz-smb.cred,uid=1000,gid=1000,file_mode=0644,dir_mode=0755,noserverino,_netdev,nofail,noauto,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.mount-timeout=10  0  0

$ id
uid=1000(NAME) gid=1000(NAME) Gruppen=1000(NAME),27(sudo)
$ id -u
1000
$ id -g
1000

Anschließend lest ihr die Konfiguration neu ein und stoßt den Mount mit einem ersten Zugriff an. Im Test klappte das auf Anhieb, und nach 60 Sekunden Ruhe löste systemd den Mount wieder, der Ordner blieb als leerer Auslöser stehen. uid und gid sollten zu eurem Konto passen, der Kasten oben zeigt, wie ihr sie findet. Ohne file_mode und dir_mode erscheinen alle Dateien als ausführbar:

$ sudo systemctl daemon-reload
$ ls /mnt/fritz

Alternative für Fortgeschrittene: systemd-Einheiten statt fstab

Wer lieber mit systemd-Einheiten arbeitet, schreibt statt der fstab-Zeile eine .mount– und eine .automount-Datei. Das Ergebnis ist dasselbe, denn systemd erzeugt aus der fstab ohnehin genau diese Einheiten. Der Vorteil: Jede Einheit lässt sich einzeln mit systemctl status prüfen, und die Meldungen landen mit journalctl -u mnt-fritz.mount in einem eigenen Protokoll.

Die Dateinamen sind nicht frei wählbar, sie müssen dem Pfad des Mountpunkts entsprechen. Aus /mnt/fritz wird mnt-fritz. Beide Dateien liegen in /etc/systemd/system/. Den Mountpunkt braucht ihr nicht von Hand anzulegen, systemd erstellt /mnt/fritz beim ersten Einhängen selbst. Welchen Namen systemd erwartet, zeigt systemd-escape, für die erste Datei lautet er mnt-fritz.mount:

$ systemd-escape -p --suffix=mount /mnt/fritz
mnt-fritz.mount

[Unit]
Description=Fritzbox-Freigabe FRITZ.NAS
After=network-online.target
Wants=network-online.target

[Mount]
What=//fritz.box/FRITZ.NAS
Where=/mnt/fritz
Type=cifs
Options=credentials=/etc/fritz-smb.cred,uid=1000,gid=1000,file_mode=0644,dir_mode=0755,noserverino
TimeoutSec=10

Dazu kommt mnt-fritz.automount. Die Optionen _netdev, nofail, noauto und die x-systemd.…-Einträge der fstab-Zeile entfallen, denn ihre Aufgaben übernehmen die Abschnitte der Einheiten: After=network-online.target wartet auf das Netz, und TimeoutIdleSec=60 trennt die Verbindung nach einer Minute Ruhe. Die .automount-Datei sorgt dafür, dass die Freigabe erst beim ersten Zugriff eingehängt wird und nach einer Weile ohne Zugriff wieder verschwindet. Sie hört auf denselben Mountpunkt wie die .mount-Datei:

[Unit]
Description=Fritzbox-Freigabe FRITZ.NAS bei Zugriff einhängen

[Automount]
Where=/mnt/fritz
TimeoutIdleSec=60

[Install]
WantedBy=multi-user.target

Eingeschaltet wird die .automount-Datei, nicht die .mount-Datei. Zuerst liest systemd die neuen Dateien ein, danach startet der Automount sofort und nach jedem Neustart von selbst. Im Test stand der Mountpunkt dann als autofs bereit, der eigentliche Mount war noch inaktiv. Der erste Zugriff hängte die Freigabe ein, und nach 75 Sekunden Ruhe war wieder nur der autofs-Auslöser übrig:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now mnt-fritz.automount
$ ls /mnt/fritz

Ein weiterer Vorteil zeigt sich bei Diensten, die ohne die Freigabe nicht laufen sollen, etwa ein Backup oder ein Medienserver. Sie tragen in ihrer Einheit eine einzige Zeile im Abschnitt [Unit] ein. Im Test hängte systemd die Freigabe beim Start eines solchen Dienstes selbst ein und startete ihn erst danach. In systemctl list-dependencies taucht mnt-fritz.mount dann als Abhängigkeit auf. Mit der fstab-Zeile ist das nur über Umwege möglich:

[Unit]
RequiresMountsFor=/mnt/fritz

Wer einen Laptop mit wechselnden Netzen hat, findet in einem älteren Artikel zum NetworkManager-Dispatcher eine weitere Variante samt Fallstricken. Dort wird die Freigabe per Skript eingehängt, sobald das Heimnetz erreichbar ist, und beim Netzwechsel wieder getrennt. Das ist eine Alternative zum Automount, wenn die Verbindung wirklich nur im Heimnetz bestehen soll.

Mehrere Benutzer und Rechner

Die Rechte vergibt die Fritzbox, nicht Linux. Jeder Benutzer unter System | FRITZ!Box-Benutzer bekommt die Berechtigung Zugang zu NAS-Inhalten. Beim Bearbeiten des Benutzers (Stift-Symbol) legt ihr fest, wie weit sie reicht: Vollzugriff zum Lesen und Schreiben, Nur Lesezugriff oder Individuelle Einstellungen. Bei der individuellen Variante wählt ihr Verzeichnis für Verzeichnis, wo der Benutzer lesen und wo er auch schreiben darf.

Sinnvoll ist ein Benutzer pro Person statt eines Kontos für alle. Dann lässt sich ein Konto später wieder sperren, ohne dass die anderen ein neues Passwort brauchen, und ein Gast oder ein Kind bekommt nur Nur Lesezugriff. Dasselbe Konto darf sich von mehreren Rechnern gleichzeitig anmelden, das funktionierte im Test ohne Probleme. Ändert ihr ein Passwort, müsst ihr die Zugangsdatei in der fstab anpassen.

Die Linux-Rechte auf dem eingehängten Ordner sind dagegen nur eine Fassade. Sie bestimmen lediglich, was ls -l anzeigt: Im Test meldete chmod 600 Erfolg und ließ den Modus trotzdem bei 644, und chown root änderte den Besitzer nicht. Wer wirklich etwas absperren will, tut das in der Fritzbox, nicht mit chmod. Dasselbe gilt für die Optionen uid, gid, file_mode und dir_mode der fstab-Zeile: Sie ändern nur die Anzeige.

Auf einem Rechner mit mehreren Konten hat der fstab-Mount genau eine Anmeldung, und jeder lokale Benutzer, der in den Ordner kommt, arbeitet mit den Rechten dieses Fritzbox-Benutzers. Mit dir_mode=0755 konnte im Test sogar der Systembenutzer nobody den Ordner auflisten. Setzt auf gemeinsam genutzten Rechnern dir_mode=0700 oder eine eigene Gruppe mit gid= und dir_mode=0770. Der Weg über Dateien in GNOME oder KDEs Dolphin meldet dagegen jedes Konto einzeln an.

Auch der Zwischenspeicher spielt hinein. Mit den Standardeinstellungen sah der zweite Rechner eine geänderte Datei sofort. Mit cache=loose,actimeo=30 las er eine Sekunde nach der Änderung noch den alten Inhalt. Für Ordner, in die mehrere Leute schreiben, bleibt es deshalb beim Standard. In jedem Fall gehört die Freigabe ins Heimnetz. Öffnet den SMB-Port 445 der Fritzbox nie ins Internet, von unterwegs reicht ein VPN.

Weitere Wege: smbclient, FTP und rclone

Zum einmaligen Kopieren reicht das Paket smbclient. Es braucht keinen Mount und keine Zusatzrechte, die Zugangsdatei von oben lässt sich mit -A wiederverwenden. Auch FTP funktioniert, sobald ihr Zugriff über FTP eingeschaltet habt: Die Fritzbox hat dann den Port 21 offen, und curl lädt Dateien hoch. Dolphin und Nautilus verstehen ftp:// ebenfalls, nur ist es als Dauerlösung unbequem. Download mit smbclient und Upload per FTP sehen so aus:

$ smbclient //fritz.box/FRITZ.NAS -A /pfad/zur/cred -c "get datei"
$ curl --user BENUTZER -T datei ftp://fritz.box/

Beispiel: nächtliches Backup auf die Fritzbox

Ein typischer Einsatz für smbclient ist ein Backup, das nachts läuft. Das Skript packt einen Ordner zu einem tar.gz-Archiv und schiebt es auf die Freigabe. Der Wochentag steckt im Dateinamen, so liegen dort höchstens sieben Archive, die sich der Reihe nach überschreiben, und ihr braucht kein Skript zum Aufräumen. Die Zugangsdatei ist dieselbe wie bei der fstab, NAME_DES_STICKS ersetzt ihr durch den Ordner eures Sticks:

#!/bin/bash
# Nächtliches Backup: Ordner als tar.gz auf die Fritzbox schieben
set -euo pipefail

QUELLE="$HOME/Dokumente"                 # dieser Ordner wird gesichert
FREIGABE="//fritz.box/FRITZ.NAS"
ZIEL="NAME_DES_STICKS/Backup"            # Ordner auf der Freigabe
CRED="$HOME/.fritz-smb"                  # Zugangsdatei mit username= und password=
DATEI="/tmp/backup-$(date +%a).tar.gz"   # Wochentag im Namen: sieben Archive im Wechsel

tar -czf "$DATEI" -C "$(dirname "$QUELLE")" "$(basename "$QUELLE")"
smbclient "$FREIGABE" -A "$CRED" -c "mkdir $ZIEL" >/dev/null 2>&1 || true
smbclient "$FREIGABE" -A "$CRED" -c "put $DATEI $ZIEL/$(basename "$DATEI")"
rm -f "$DATEI"

Für einen Test lasst ihr das Skript zweimal laufen: Beim ersten Mal legt es den Zielordner an, beim zweiten überschreibt es das Archiv vom selben Wochentag. Bei einem unmöglichen Ziel endet es mit Fehlercode 1, damit ein Timer den Fehler im Protokoll festhält. Das Zurückholen eines Archivs und das Auspacken klappten ebenfalls, nur der Wochentag im Dateinamen muss zum gewünschten Stand passen:

$ smbclient //fritz.box/FRITZ.NAS -A ~/.fritz-smb -c "get NAME_DES_STICKS/Backup/backup-Mo.tar.gz"
$ tar -xzf backup-Mo.tar.gz

Wer FTP bevorzugt, ersetzt die beiden smbclient-Zeilen durch einen curl-Aufruf. Der Zielordner wird dabei von selbst angelegt. Die Zugangsdaten stehen in einer eigenen Datei im Home-Verzeichnis, die nur ihr lesen dürft (chmod 600), damit das Passwort weder im Skript noch in der Prozessliste auftaucht. Auch das sollte bei euch im Test funktionieren, das Archiv landete im Zielordner auf dem Stick:

$ install -m 600 /dev/null ~/.fritz-netrc
$ nano ~/.fritz-netrc

machine fritz.box login DEIN_FRITZBOX_BENUTZER password DEIN_PASSWORT

curl --fail --silent --show-error --ftp-create-dirs \
     --netrc-file "$HOME/.fritz-netrc" \
     -T "$DATEI" "ftp://fritz.box/$ZIEL/$(basename "$DATEI")"

Für die Nacht braucht ihr einen Timer. Unter systemd genügen zwei kleine Dateien im Benutzerordner ~/.config/systemd/user/, das Skript liegt als ~/bin/fritz-backup.sh. Der Dienst startet das Skript, und der Timer ruft ihn um 2:30 Uhr auf. Persistent=true holt einen verpassten Lauf nach, etwa wenn der Rechner um diese Zeit aus war:

[Unit]
Description=Backup auf die Fritzbox

[Service]
Type=oneshot
ExecStart=%h/bin/fritz-backup.sh

[Unit]
Description=Backup auf die Fritzbox jede Nacht

[Timer]
OnCalendar=*-*-* 02:30
Persistent=true

[Install]
WantedBy=timers.target

Eingeschaltet wird der Timer, nicht der Dienst. Der dritte Befehl startet einen Lauf sofort, damit ihr seht, ob alles klappt, und der vierte zeigt das Protokoll. Im Test stand der nächste Lauf danach für 2:30 Uhr in der Liste, und der manuell gestartete Lauf legte das Archiv auf dem Stick ab:

$ systemctl --user enable --now fritz-backup.timer
$ systemctl --user list-timers fritz-backup.timer
$ systemctl --user start fritz-backup.service
$ journalctl --user -u fritz-backup.service

Wer mehrere Cloud-Speicher und die Fritzbox über ein Werkzeug ansprechen will, nutzt rclone mit SMB-Backend. Die Freigabe wird dort als eigener Speicher angelegt, der Freigabename FRITZ.NAS steht im Pfad. Im Test funktionierten Kopieren und Spiegeln eines Ordners. Das Passwort landet bei diesem Befehl im Shell-Verlauf, wer das vermeiden will, gibt es stattdessen interaktiv über rclone config ein:

$ rclone config create fritz smb host fritz.box user DEIN_BENUTZER pass DEIN_PASSWORT --obscure
$ rclone sync ~/Dokumente fritz:FRITZ.NAS/NAME_DES_STICKS/Backup/Dokumente

Nicht möglich sind dagegen WebDAV und SSH (sshfs): Port 22 ist zu, und einen WebDAV-Zugang auf den Speicher gibt es offenbar nicht. Für den Alltag spielt das kaum eine Rolle, denn SMB und FTP decken die üblichen Fälle ab: Dateien hochladen, Backups ablegen und eine Freigabe als Ordner einhängen. Zu NFS folgt weiter unten ein eigener Abschnitt.

Tempovergleich

Gemessen wurde auf einem TUXEDO-Notebook mit Ubuntu 26.04.1, GNOME 50.1 und Kernel 7.0, angeschlossen über einen 2,5-Gbit-USB-Adapter an eine Fritzbox 5690 Pro, die an einem Gigabit-Port hängt. Getestet wurden zwei Speicher: der interne der Box (1,7 GB) und ein USB-3.0-Stick mit 128 GB. Jeder Test lief dreimal, die Tabelle zeigt den Median. Gelesen und geschrieben wurde eine 512 MB große Datei (mit Nullen gefüllt, vor jedem Lesen Cache geleert).

Dieselben Läufe wurden später auf demselben Notebook unter TUXEDO OS wiederholt (Kernel 7.2, Plasma). Die Werte liegen fast deckungsgleich: Der Kernel-Mount schreibt mit 46 bis 49 MB/s und liest mit 105 MB/s, smbclient schreibt mit 64 bis 68 MB/s, FTP mit 52 bis 65 MB/s, je nach Speicher. Abweichungen von mehr als 3 MB/s gab es nur beim Schreiben mit smbclient auf den internen Speicher (64 statt 55 MB/s).

Beim Lesen großer Dateien bremst nicht Linux, sondern das Netz: Die Fritzbox hängt an einem Gigabit-Port, und gut 100 MB/s ist knapp unter dem, was eine solche Verbindung hergibt. Intern wie am Stick kommt dasselbe heraus. Der 2,5-Gbit-Adapter des Notebooks wird dabei nicht ausgereizt. Die SMB-Version spielt keine Rolle, 2.1, 3.0 und 3.1.1 sind gleich schnell.

Beim Schreiben bleibt der Kernel-Mount bei rund 45 MB/s, egal ob intern oder am Stick. smbclient und FTP schreiben auf den USB-3-Stick dagegen mit 65 bis 71 MB/s, GVfs mit 60 MB/s. Der Speicher ist beim Kernel-Mount also nicht die Bremse, und auch das Messverfahren ist nicht die Ursache, das ist gegengeprüft.

Gefunden wurde der Grund beim Ausprobieren von Einstellungen. Puffergrößen (wsize) und andere Optionen ändern nichts, das Signieren der Pakete (sign) kostet sogar fast die Hälfte. Mit nostrictsync springt das Schreiben dagegen auf rund 95 MB/s. Die Option verhindert, dass Linux beim Schließen einer Datei verlangt, dass die Box sie auf den Datenträger schreibt. Die Box meldet dann „fertig“, bevor die Daten auf dem Stick liegen.

Bei vielen kleinen Dateien (300 Stück à 16 KB) ist GVfs deutlich abgeschlagen: Am Stick braucht es zum Schreiben 2,4 und zum Lesen 2,5 Sekunden, der Kernel-Mount nur 0,8. Für ein paar Fotos fällt das nicht auf, bei einem Ordner mit tausenden Dateien schon. Auf dem internen Speicher sah es genauso aus (2,3 gegen 0,7 Sekunden).

cache=loose bringt beim Lesen vier Prozent und beim Schreiben nichts Messbares. Die vier Prozent merkt man im Alltag kaum. Dafür sieht der Rechner Änderungen anderer Geräte später. Für ein Netzlaufwerk, auf das mehrere Leute zugreifen, sollte es aus bleiben. Die Messreihe stammt von einem Tag und einem Router, die Werte sind also Anhaltspunkte und keine Garantie.

NFS und Freetz

Die Fritzbox selbst bietet kein NFS an: Auf Port 2049 und 111 antwortet die Box nicht. Früher half das Zusatzprojekt Freetz, das unter anderem einen NFS-Server nachrüstete. Das ursprüngliche Freetz gilt als veraltet, seine letzte Version stammt aus dem Jahr 2012. In alten Foren-Beiträgen findet ihr dazu viele Anleitungen, die sich auf Boxen und Firmware-Stände beziehen, die lange nicht mehr aktuell sind.

Lebendig ist der Fork Freetz-NG, der die Arbeit des ursprünglichen Projekts weiterführt: Die News reichen bis November 2026, zuletzt erschien im September ein neuer Stand. Auch ein NFS-Server mit Weboberfläche gehört weiter dazu, der nfsd-cgi. Die Liste der unterstützten Firmwares führt viele Fritzboxen auf, darunter die 5690 Pro. Wer es ausprobieren will, sollte vorher klären, welche Firmware die eigene Box hat.

Ein Selbstläufer ist es trotzdem nicht. Freetz-NG ersetzt die Firmware der Box durch ein selbst gebautes Abbild, und laut den News laufen neuere FritzOS-8.5-Stände nur teilweise, viele Anpassungen schlagen fehl. Die Dokumentation des NFS-Servers nennt nur eine alte Fritzbox 7390 als Testgerät. Für die 5690 Pro ist es ungetestet, und der Gewinn wäre überschaubar: Beim Lesen sitzt das Netz schon an der Grenze, beim Schreiben bremst das Wegschreiben auf den Datenträger.

Erfahrungen und Messwerte

Wie hängt ihr eure Fritzbox-Freigaben ein? Erfahrungen und Tipps gehören gern in die Kommentare, besonders zu anderen Fritzbox-Modellen und Firmware-Ständen, zu USB-Datenträgern mit anderen Dateisystemen und zu Ordnerrechten pro Benutzer, die sich in diesem Test nicht klären ließen. Auch Messwerte von schnelleren Speichern oder einem 2,5-Gbit-Anschluss an der Box sind willkommen.

☕ 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.

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.