File Browser 2026 selbst hosten: Volumes, Konten und sicheres Teilen

Betrachte File Browser als kleines System und nicht als Docker-Image. Das Ziel für Benutzer ist klar: ein Web-Dateimanager für ein eingebundenes Volume. Die Bereitstellung ist jedoch erst dann akzeptabel, wenn du einen eingeschränkten Benutzer anlegen, eine Datei hochladen und umbenennen, Text bearbeiten, einen Share erstellen und bestätigen kannst, dass der Benutzer sein zugewiesenes Root-Verzeichnis nicht verlassen kann.

Diese Unterscheidung macht den Fehler sichtbar, auf den Betreiber nach lokalen Tests stoßen: Die eingebundenen Dateien verwenden Host-Berechtigungen, auf die der Container nicht zugreifen kann. Außerdem wird der Backup- und Upgrade-Plan dadurch konkret genug, um ihn zu testen.

Alle persistenten Daten von File Browser finden

Ein Container-Image kann erneut heruntergeladen werden; die bereitgestellten Dateien sowie die File-Browser-Datenbank und -Einstellungen hingegen nicht. Binde /srv vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu überprüfen, dass dieser Pfad tatsächlich persistent ist. Prüfe das tatsächlich verwendete Mount, statt dich auf einen Compose-Dateinamen zu verlassen, und stelle sicher, dass der Runtime-Benutzer dort schreiben kann, wo File Browser es erwartet.

Lege Aufbewahrungsfristen und ein Ziel außerhalb des Hosts fest und übe die Wiederherstellung, ohne die Produktion anzufassen. Die Übung ist nur dann erfolgreich, wenn bereitgestellte Dateien, Benutzer, Scopes, Shares und Einstellungen wiederhergestellt werden und ein eingeschränktes Konto weiterhin auf seinen Bereich beschränkt bleibt. Für datenbankgestützte Zustände solltest du Storage-Snapshots mit applikationskonsistenten Exporten kombinieren, wie unter Point-in-Time-Recovery und Snapshots beschrieben.

Die erste produktionsnahe Instanz starten

Halte den ersten File-Browser-Aufruf so reproduzierbar, dass er in einem Pull Request überprüft werden kann.

docker run -d \
  --name file-browser \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v file-browser-data:/srv \
  -v file-browser-db:/database \
  -v file-browser-config:/config \
  filebrowser/filebrowser:latest

Verlasse dich nicht auf latest, sobald echte Daten vorhanden sind. Halte den funktionierenden Digest, den Container-Benutzer und die Eigentümer der Mounts fest. Verfolge das Anwendungslog über einen vollständigen Test hinweg – eingeschränkten Benutzer anlegen, eine Datei hochladen und umbenennen, Text bearbeiten, einen Share erstellen und bestätigen, dass der Benutzer sein zugewiesenes Root-Verzeichnis nicht verlassen kann – und notiere alle Migrationen, bevor du die Route dem Produktiv-Traffic aussetzt.

Die Runtime-Grenze von File Browser festlegen

Prozessgesundheit und Produktgesundheit sind bei File Browser zwei verschiedene Dinge. Port 80 kann antworten, während der eigentliche Benutzer-Workflow weiterhin fehlschlägt. Die lokale Runtime-Anforderung ist ein separater persistenter Pfad für die Datenbank und die Einstellungen. Validiere dies unter der vorgesehenen Akzeptanzlast; ein inaktiver Health Check kann nicht belegen, dass die Ressource ausreicht.

Verwende diese Readiness-Übung nach wichtigen Konfigurationsänderungen: eingeschränkten Benutzer anlegen, eine Datei hochladen und umbenennen, Text bearbeiten, einen Share erstellen und bestätigen, dass der Benutzer sein zugewiesenes Root-Verzeichnis nicht verlassen kann. Halte aufwendige externe Prüfungen aus Liveness-Probes heraus, damit ein Ausfall eines Providers keine Restart-Schleife verursacht. Bei der Kapazitätsplanung solltest du den zugrunde liegenden Disk-Durchsatz, die Upload-Größe, parallele Downloads und die Anzahl der Verzeichnisse verfolgen. Diese Werte bilden die tatsächliche Belastung von File Browser besser ab als Seitenaufrufe.

Die öffentliche Origin eindeutig festlegen

Stelle für File Browser einen einzigen HTTPS-Hostnamen bereit und halte den direkten Port 80 privat. Veröffentliche die UI über HTTPS, aber beschränke das bereitgestellte Root-Verzeichnis sorgfältig. So verhinderst du, dass Browser und API-Clients zwei konkurrierende Adressen kennenlernen.

Führe den bekannten funktionierenden Workflow von einem sauberen Client aus und untersuche die erste fehlschlagende Anfrage. Verwende den Leitfaden für eigene Domains, wenn DNS oder TLS fehlerhaft sind. Behandle „Die eingebundenen Dateien verwenden Host-Berechtigungen, auf die der Container nicht zugreifen kann“ als separate Anwendungsdiagnose, sobald die Route nachweislich funktioniert.

Das Release-Gate für File Browser

Erstelle ein kleines, kurzlebiges File-Browser-Testsystem und behalte es für jedes Release. Das Fixture sollte den echten Workflow abbilden: eingeschränkten Benutzer anlegen, eine Datei hochladen und umbenennen, Text bearbeiten, einen Share erstellen und bestätigen, dass der Benutzer sein zugewiesenes Root-Verzeichnis nicht verlassen kann. Dokumentiere den Image-Digest, den externen Hostnamen, die Dependency-Adresse und das erwartete Ergebnis, damit ein späterer Betreiber den Test wiederholen kann, ohne diesen Leitfaden interpretieren zu müssen.

Führe das Fixture dreimal aus. Verwende zuerst die frische Bereitstellung. Ersetze anschließend den Container, ohne persistente Daten anzutasten. Stelle im dritten Schritt das Backup in einer leeren Umgebung wieder her. Der dritte Lauf ist nur dann erfolgreich, wenn bereitgestellte Dateien, Benutzer, Scopes, Shares und Einstellungen wiederhergestellt werden und ein eingeschränktes Konto weiterhin auf seinen Bereich beschränkt bleibt. Erfasse bei jedem Lauf Latenz und Ressourcennutzung im Zusammenhang mit dem zugrunde liegenden Disk-Durchsatz, der Upload-Größe, parallelen Downloads und der Anzahl der Verzeichnisse. Diese Werte bilden die Grundlage für Alerts und nicht etwa ein willkürlich gewählter CPU-Prozentsatz.

Teste abschließend absichtlich den Negativpfad: Sende harmlose Eingaben nahe am Ressourcen- oder Formatlimit, das mit dieser Grenze verbunden ist: Die eingebundenen Dateien verwenden Host-Berechtigungen, auf die der Container nicht zugreifen kann. Stelle sicher, dass File Browser sichtbar fehlschlägt, ohne den Zustand zu beschädigen, behebe die Ursache und wiederhole den erfolgreichen Workflow. Ein Release-Eintrag mit diesen vier Ergebnissen liefert bessere Belege als Dashboard-Screenshots oder eine einmalige curl-Antwort.

Kapazitäts- und Upgrade-Prüfungen

Ein inaktiver Health Check sagt wenig über File Browser aus. Beobachte den zugrunde liegenden Disk-Durchsatz, die Upload-Größe, parallele Downloads und die Anzahl der Verzeichnisse. Löse anschließend anhand des Symptoms aus, das Benutzer tatsächlich erleben: dem Fehlschlagen der Aktion „eingeschränkten Benutzer anlegen, eine Datei hochladen und umbenennen, Text bearbeiten, einen Share erstellen und bestätigen, dass der Benutzer sein zugewiesenes Root-Verzeichnis nicht verlassen kann“. Halte Liveness lokal und kostengünstig; Readiness sollte Migrationen oder Initialisierung melden, ohne eine Restart-Welle auszulösen.

Der kritische Bereich bei Upgrades besteht darin, dass Migrationen der File-Browser-Datenbank und -Einstellungen relevant sind, auch wenn die bereitgestellten Dateien auf einem separaten Mount liegen. Lies die Release Notes, erstelle einen Snapshot des Zustands, stelle die Zielversion gegen eine wiederhergestellte Kopie bereit und wiederhole die Akzeptanzaktion. Wenn die eingebundenen Dateien Host-Berechtigungen verwenden, auf die der Container nicht zugreifen kann, korreliere die Client-Anfrage mit dem ersten relevanten Anwendungslog, statt den Zustand zu löschen oder blind Redirects hinzuzufügen.

Die Berechtigungen von File Browser reduzieren

Bootstrap-Zugangsdaten sind temporär; das Trust Model bleibt dauerhaft bestehen. Achte bei File Browser darauf, nicht / oder ein Secrets-Verzeichnis statt eines dedizierten Shares bereitzustellen. Verwende ein dediziertes Verzeichnis anstelle des Host-Roots und gib jedem Konto den kleinstmöglichen erforderlichen Dateibereich.

File Browser benötigt in dieser Ausgangskonfiguration kein obligatorisches Bootstrap-Secret. Schütze stattdessen das tatsächliche Administratorkonto oder die vorgeschaltete Authentifizierung. Starte das Image ohne unnötige Linux-Capabilities und veröffentliche ausschließlich die öffentliche Anwendungsroute. Halte Administratoraktivitäten nachvollziehbar, ohne Secret-Werte zu protokollieren.

Dockup für die Plattformebene verwenden

Für File Browser ist Dockup besonders an der Grenze zwischen einem Image und einem persistenten Service hilfreich. Dockup hält die Route zu Port 80, TLS, Secret-Werte und den eingebundenen Storage über Container-Ersetzungen hinweg verfügbar – unabhängig davon, ob die Compute-Ressourcen zu Dockup oder zu deinem angebundenen Server gehören.

Schließe mit anwendungsspezifischen Prüfungen ab: Veröffentliche die UI über HTTPS, aber beschränke das bereitgestellte Root-Verzeichnis sorgfältig. Bestätige die lokale Anforderung – ein separater persistenter Pfad für Datenbank und Einstellungen – und führe diese Prüfung aus: eingeschränkten Benutzer anlegen, eine Datei hochladen und umbenennen, Text bearbeiten, einen Share erstellen und bestätigen, dass der Benutzer sein zugewiesenes Root-Verzeichnis nicht verlassen kann. Halte das Ergebnis als Deployment-Check fest, damit das nächste Image-Update anhand des Verhaltens und nicht anhand des Container-Status bewertet wird.

Häufig gestellte Fragen

Was benötigt File Browser für eine produktive Bereitstellung?

Leite den File-Browser-Container auf Port 80 über eine einzige HTTPS-Origin. Die lokale Runtime-Anforderung ist ein separater persistenter Pfad für die Datenbank und die Einstellungen. Erkläre File Browser erst dann für bereit, wenn du einen eingeschränkten Benutzer anlegen, eine Datei hochladen und umbenennen, Text bearbeiten, einen Share erstellen und bestätigen kannst, dass der Benutzer sein zugewiesenes Root-Verzeichnis nicht verlassen kann.

Welche File-Browser-Daten gehören in ein Backup?

Mache /srv persistent und nimm die bereitgestellten Dateien sowie die File-Browser-Datenbank und -Einstellungen in dasselbe Wiederherstellungsmanifest auf. Eine saubere Wiederherstellung von File Browser ist nur dann erfolgreich, wenn bereitgestellte Dateien, Benutzer, Scopes, Shares und Einstellungen zurückkehren und ein eingeschränktes Konto weiterhin auf seinen Bereich beschränkt bleibt.

Benötigt File Browser HTTPS hinter einem Reverse Proxy?

Verwende HTTPS für die öffentliche File-Browser-Origin und halte Port 80 auf der internen Route. Setze die File-Browser-Einstellung korrekt: Veröffentliche die UI über HTTPS, aber beschränke das bereitgestellte Root-Verzeichnis sorgfältig. Bei File Browser schützt HTTPS Zugangsdaten oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes clientseitiges Verhalten, das von der Origin abhängt.

Wie sollte ein File-Browser-Upgrade getestet werden?

Stelle den aktuellen File-Browser-Zustand in einer isolierten Bereitstellung wieder her, wende die Kandidatenversion an und wiederhole den Akzeptanz-Workflow. Achte besonders darauf, dass Migrationen der File-Browser-Datenbank und -Einstellungen relevant sind, auch wenn die bereitgestellten Dateien auf einem separaten Mount liegen. Behalte das vorherige File-Browser-Image, bis die Grenzen von Datenmigration und Rollback verstanden sind.