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.

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.

Bei all der Freude über ein fortwährend aktuelles System gibt es ab und an kleine Unstimmigkeiten bei der Installation von Software-Updates. Es kann schon mal passieren, dass eine neue Version einen Bug mitbringt. Da Arch aber eng am Upstream sitzt, ist dieser meist auch schnell wieder behoben. Die größten Pannen entstehen jedoch nicht durch die Systemupdates: Der größte anzunehmende Fehler sitzt in der Regel vor dem Bildschirm. So fiel bei mir schon einmal während eines Pacman-Updates der Strom aus oder ich habe die Konfiguration des Bootmanagers verbastelt.

HINWEIS: Das hier geschilderte Vorgehen funktioniert selbstverständlich auch bei anderen Linux-Distributionen wie auch mit anderen Live-Linuxen. Im Endeffekt geht es immer darum, das eigentlich installierte System in einem Live-Linux per Chroot einzubinden, um in diesem mit dem eigentlich installierten System arbeiten zu können, ohne es booten zu müssen.

Das Ergebnis ist am Ende meist dasselbe: Wenn man sehr sehr viel Pech hat, dann lässt sich Arch nicht mehr booten. Aus diesem Grunde habe ich bei mir auch immer einen USB-Stick mit einem Ubuntu-System liegen. Von diesem Notfall-System aus lässt sich Arch in der Regel wiederbeleben — egal was zuvor passiert ist. Hat man nur eine Konfigurationsdatei wie die /etc/fstab oder die /boot/syslinux/syslinux.cfg verbastelt, dann kann man diese ja leicht von der Live-CD aus bearbeiten. Hängt allerdings das System, weil zum Beispiel Pacman jäh unterbrochen wurde, dann braucht es ein anderes Kaliber: Ein Chroot in die nicht mehr bootende Arch-Installation.

Arch-Chroot aus Ubuntu

Damit das klappt, müsst ihr euren Rechner von einer Linux-Live-DVD oder einem USB-Stick mit Linux booten. Für meine Zwecke reicht ein USB-Stick mit Ubuntu 14.04 und persistenter Partition aus, so muss ich nicht immer wieder die Spracheinstellungen korrigieren oder den WLAN-Zugang neu einrichten. Ist das Live-System geladen, öffnet ihr als erstes ein Terminal und schaut euch an, welche Device-IDs die in eurem System verbauten Festplatten und Partitionen bekommen haben. Am einfachsten klappt dies in meinen Augen immer mit dem Befehl lsblk.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 232,9G 0 disk
├─sda1 8:1 0 26G 0 part
├─sda2 8:2 0 202,9G 0 part
└─sda3 8:3 0 4G 0 part [SWAP]
sde 8:64 1 1000M 0 disk
├─sde1 8:65 1 964M 0 part
└─sde2 8:66 1 2,3M 0 part
loop0 7:0 0 922M 1 loop /rofs

In meinem Fall sitzt das ganze System auf einer 256 GByte großen SSD, also ist /dev/sda das richtige Gerät. Nun weiß ich, dass bei meinem Rechner auf /dev/sda1 das System, auf /dev/sda3 die Homeverzeichnisse und auf /dev/sda4 das Boot-Verzeichnis liegt; kennt ihr euch auf eurem System nicht so gut aus und lässt sich auch aus der Partitionsgröße nicht auf die Zugehörigkeit schließend, dann könnt ihr aus dem Dateimanager heraus die Partitionen kurz einbinden und so direkt nachsehen, welche Daten wo liegen.

Ist die Frage geklärt, holt ihr euch mit sudo -s Root-Rechte und erzeugt einen Mount-Punkt für euer Arch-System im aktuellen Live-Linux; für mein Beispiel nutze ich einfach /arch. In dieses mountet ihr zuerst die Systempartition, dann die Homepartition nach /arch/home und schließlich — natürlich nur wenn /boot auch auf einer eigenen Partition liegt — die Bootpartition eures Arch-Systems.

$ sudo -s
$ mkdir /arch
$ mount /dev/sda1 /arch
$ mount /dev/sda2 /arch/home
### Falls ihr weitere Partitionen nutzt...
$ mount /dev/sda4 /arch/boot

Damit das Chroot später komplett funktioniert, müsst ihr nun noch Symlinks zu dynamischen Verzeichnissen des Live-Systems wie /proc oder /dev in den zukünftigen Chroot-Bereich legen. Alleine mit diesen Symlinks würde allerdings der Netzwerkzugang inklusive Namensauflösung noch nicht korrekt funktioniern, holt euch daher noch die resolv.conf des Live-Linux in das Chroot rüber. Ist das alles geschehen, öffnet ihr schließlich mit dem Chroot-Befehl euer Arch-Linux — ohne es vorher Booten zu müssen.

$ mount -t proc none /arch/proc
$ mount -t sysfs none /arch/sys
$ mount -o bind /dev /arch/dev
$ mount -o bind /dev/pts /arch/dev/pts # Wichtig für Pacman
$ cp -L /etc/resolv.conf /arch/etc # Für Netzwerkzugriff
$ chroot /arch bash

Im Chroot arbeitet ihr nun mit sämtlichen Daten eures Arch-System, die Wurzel des Verzeichnisbaums beginnt wie gewohnt bei / und nicht mehr mit dem zuvor erstellten Mountpunkt. Zum Bearbeiten der fstab wechselt ihr also einfach nur nach /etc und öffnet dort die Fstab-Datei mit einem Editor wie zum Beispiel Nano: nano /etc/fstab. Ihr braucht sogar auf Programme mit einer graphischen Oberfläche nicht verzichten, dazu müsst ihr lediglich den Xserver des Ubuntu-Systems mit xhost + für Zugriffe von außen öffnen.

Befehle wie pacman -Syu zum Einspielen von Updates oder etwa syslinux-install_update -i -a -m für die Neu-Installation des Syslinux-Bootloaders lassen sich direkt aus dem Chroot ausführen, als ob ihr aus eurem Arch-System heraus arbeiten würdet. Mit ein bisschen Ellbogenschmalz und Geschick beim Googeln nach Fehlermeldungen bekommt man sein Arch danach in der Regel wieder recht schnell flott, sodass man wieder ganz normal von der Festplatte oder der SSD booten kann.

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

Um Support für NFS auf die gefreetzte FRITZ!Box zu bekommen, müsst ihr nfs-utils und NFSD_CGI in das Freetz-Image einbauen. Eine entsprechende Anleitung für Freetz habe ich ja schon hier im Blog gebracht. Ich konzentriere mich daher lieber auf die Konfiguration von NFS und die Auswirkungen auf die Netzwerkperformance der Box. Um Freetz auf die FRITZ!Box zu bekommen, lest euch zuvor bitte in den genannten Artikel zu Freetz ein.

Freigaben via NFS einrichten und konfigurieren

Nach der Aufnahme der beiden Module in euer Freetz-Image und einem anschließenden Neustart, könnt ihr NFS unter http://fritz.box:81/cgi-bin/conf/nfsd konfigurieren. Die Konfigurationen für die exports, hosts.allow, hosts.deny und Co. könnt ihr dabei aus der nfsd-Doku von Freetz übernehmen. Nehmt am besten auch den SSH-Server Dropbear mit in euer Image auf, so könnt ihr später ganz einfach über SSH mit der FRITZ!Box arbeiten, um etwa die Dateirechte auf dem externen Datenträger zu korrigieren.

Wichtig dabei ist allerdings, dass ihr als freizugebendes Medium Platten verwendet, die mit Ext3 oder ReiserFS formiert sind (Ext4 ginge natürlich auch, allerdings hatte ich Probleme beim Einbinden von mit Ext4 formatierten Partitionen, von daher gebe empfehle ich eher Ext3 als Dateisystem). Mit hoher Wahrscheinlichkeit müsst ihr auf dem Laufwerk auch noch die Dateirechte korrigieren, ich logge mich dazu via SSH auf der FreetzBox ein und übergebe die Daten dem User „ftp“ und der Gruppe „users“.

$ ssh root@fritz.box 
$ cd /var/media/ftp/
# Bitte passt den Pfad zur Platte an, bei mir nennt sie sich datengrab
$ chown ftp:users datengrab -R
$ find datengrab/ -type d -exec chmod 775 {} +
$ find datengrab/ -type f -exec chmod 664 {} +

Danach könnt ist auf Seiten der FRITZ!Box alles erledigt. Ihr müsst nun auf eurem Linux-System den NFS-Client installieren und die Freigabe bei euch einbinden. Auf einem Debian/Ubuntu-System installiert ihr dafür erst einmal das Paket nfs-common, legt dann einen Mount-Punkt an (nichts anderes als ein Verzeichnis, in das die Freigabe geladen wird) und bearbeitet dann die Datei /etc/fstab so dass die NFS-Freigabe der FRITZ!Box geladen wird.

$ sudo apt-get install nfs-common
$ sudo mkdir /media/fritzbox
$ gksudo gedit /etc/fstab

Der Eintrag in die fstab sähe z.B. so aus. Den Pfad zu Freigabe und zum Mountpunkt müsst ihr natürlich noch an eure Situation anpassen. Den Rest könnt ihr direkt übernehmen und ans Ende der fstab kopieren.

# Freetzbox über NFS mounten
fritz.box:/var/media/ftp/datengrab /media/fritzbox nfs vers=3,rw,rsize=65536,wsize=65536 0 0

Nach dem Speichern der Datei, könnt ihr über das folgende Kommando alle über die fstab eingetragenen Mount-Vorgänge neu einlesen lassen, so spart ihr euch noch einen Neustart oder das manuelle Ausführen eines längeren mount-Kommandos.

$ sudo mount -a

Nun sollte die Netzwerkfreigabe der FreetzBox unter /media/fritzbox erscheinen. Testet am besten kurz aus, ob ihr dort lesen und schreiben könnt. Sollte das nicht der Fall sein, so wird vermutlich noch etwas mit den Dateirechten nicht stimmen.

Was bringt nun NFS auf der FRITZ!Box?

Zum Abschluss komme ich nun auf die ursprüngliche Frage zurück, lohnt sich der Aufwand eigentlich? Der springende Punkt dabei ist natürlich die Übertragungsrate von Daten zur FRITZ!Box. Ursprünglich hing an meiner unmodifizierte FRITZ!Box eine mit NTFS formatierte USB-Platte. Subjektiv beurteilt war diese Lösung grottig langsam, Transfers größerer Datenmengen von 3-4 GB dauerten Stunden und auch das Einlesen von Verzeichnissen mit vielen Dateien/Ordner war zeitraubend. Nach dem Freetzen und Umstellen auf Ext3 als Dateisystem und NFS als Dateifreigabe sieht das nun deutlich anders aus…

$ time cp 1gb.test /media/fritzbox_samba/
real	4m56.363s
$ time cp ubuntu-11.04-desktop-i386.iso /media/freetz_nfs/
real	1m58.300s
$ time cp ubuntu-11.04-desktop-i386.iso /media/freetz_samba/
real	2m14.387s

Errechne ich nun aus diesen Zeiten eine Datenübertragungsrate, so kommt wieder NFS vor Samba ans Ziel. Immerhin ist NFS nach wie vor rund 0,7 MB/s schneller als Samba, allerdings ist der Unterschied nicht mehr so gravierend wie damals mit meiner NLSU2.

Die Verbesserten Übertragungsraten spürt man auch im Linux-Alltag. Natürlich spart man beim Kopieren größerer Datenmengen deutlich Zeit, aber auch das „Browsen“ mit Nautilus auf der Freigabe geht spürbar schneller. Vorher war immer eine kurze Denkpause nach dem Wechsel eines Verzeichnisses nötig, jetzt ist der Inhalt sofort da. Vorher dauerte das Einlesen eines Verzeichnisses mit VIELEN Dateien wirklich lange, jetzt ist auch dieses Verzeichnis sofort da. Der Umstieg auf Freetz und NFS ist daher auf jeden Fall lohnenswert.

Den gewaltigen Performance-Vorsprung gegenüber der ursprünglichen Konfiguration (NTFS und Original-Firmware) führe ich auf das Dateisystem NTFS zurück. Ich habe schon selbst bei mir auf meinem Desktop-Rechner mit Intel Core i3 festgestellt, dass NTFS unter Linux ziemlich auf die CPU geht, das ist natürlich fatal bei einem auf einem Embeded-Linux, bei dem nur eine leistungsschwache CPU zur Verfügung steht.

Ich hatte es leider verpasst die Netzwerkperformance einer freigegeben und mit FAT formatierten Platte zu messen, aber ich denke dass hier ein Plus an Geschwindigkeit definitiv messbar sein wird. Wer also mit den Übertragungsraten seiner FRITZ!Box nicht zufrieden ist, die Box jedoch nicht „freetzen“ möchte, der kann ja mal seine externe Platte auf FAT umstellen [UPDATE: Neuere FRITZ!Boxen können auch direkt mit Ext2 formatierte Laufwerke einbinden, vielleicht ist das die beste Option für ungefreetzte Boxen].

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