Am 01-09-2026 hat Henrique Dias sein Projekt File Browser auf GitHub archiviert. Über zehn Jahre lang war das der Dateimanager, den man in einer Minute vor einen Ordner stellte: Docker-Image ziehen, Port aufmachen, fertig. Jetzt steht im README, dass es keine weiteren Releases, keine Bugfixes und keine Sicherheitsfixes mehr gibt. Wer es noch laufen hat, betreibt ab sofort Software ohne Wartung, und für einen Dienst, der Dateien hochladen, löschen und teilen darf, ist das keine Kleinigkeit.

Der Nachfolger, über den auf Lemmy und in den Kommentaren zum Abschied am meisten geredet wird, heißt FileBrowser Quantum. Graham Steffaniak hat das Original abgezweigt und in eigener Richtung weitergebaut: über 8.000 Sterne, Apache-Lizenz, ein stabiles Release vom 04-09-2026 mit Sicherheitsfix, und die Shell-Befehle aus dem Original sind komplett gestrichen. Genau das würde ich mir wünschen, wenn ich ein Werkzeug mit Schreibrechten auf meine Dateien tausche. Diese Anleitung installiert es mit Docker Compose, setzt das Passwort, bevor der erste Browser dran darf, und zeigt, wo es in den Issues und im Lemmy-Thread hakt.

Kurz gesagt: Am Ende läuft FileBrowser Quantum als Container auf deinem Server, zeigt im Browser einen Ordner deiner Wahl, hat ein eigenes Admin-Passwort statt admin/admin, und du weißt, welche zwei Dateien du sichern musst. Dauer rund 20 Minuten, Stufe Standard. Stand: FileBrowser Quantum 1.5.6-stable, geprüft am 10-09-2026.
FileBrowser Quantum in drei Schritten: zwei Dateien anlegen, Container starten, Passwort und Rechte setzen
Der ganze Weg auf einen Blick: Schritt 3 ist der, den viele beim Original nie gegangen sind.
Fork? Eine Abzweigung. Der Quellcode des Originals ist frei, also darf jeder eine Kopie nehmen und in eigener Richtung weiterbauen. Quantum hat so angefangen, sich aber weit vom Original entfernt: neue Oberfläche, eigene Konfigurationsdatei, anderes Rechtemodell. Es ist ein anderes Programm mit demselben Vornamen.

Warum Quantum, und warum die stabile Version

Dias schreibt in seinem Abschiedsbeitrag, warum er aufhört: Er hat File Browser mit 15 geschrieben, und der Code müsste „from the ground up, with security and a good API in mind" neu entstehen. Das ist ehrlich, und es erklärt, warum ein Fork, der nur Bugs fixt, das Problem nicht lösen würde. Quantum hat den Unterbau umgebaut und dabei zwei Dinge getan, die mir gefallen: Die Terminal-Funktion des Originals, mit der ein Admin Shell-Befehle auf dem Server ausführen konnte, gibt es nicht mehr. Und Freigaben können ein Passwort, ein Ablaufdatum und ein Download-Limit haben.

Eine Entscheidung musst du vor dem ersten Befehl treffen. Quantum gibt es in zwei Linien: 1.5.x ist stabil, 2.0 ist seit Juli in der Beta und bringt eine neue Datenbank samt Rechtemodell mit. Die Doku behandelt 2.0 schon als Hauptversion, und das ist verlockend. Ich würde trotzdem die stabile Linie nehmen. Am 07-09-2026 kam die fünfte Beta, und in ihr steckt derselbe Sicherheitsfix wie im stabilen Release: Die öffentliche Metadaten-API gab Dateiinhalte an anonyme Besucher einer Freigabe heraus, an Download-Limit und Viewer-Einstellung vorbei. Beide Linien werden also gepflegt, aber nur eine heißt stabil. Und wenn 2.0 fertig ist, tauschst du nicht einfach das Image-Tag: Die Doku beschreibt für den Umstieg eine Datenbank-Migration mit Sicherung, Umbenennung und Rückweg. Das ist ein eigener Abend, und den planst du besser, als dass er dich überrascht.

Browser→ Port 8080 →FileBrowser Quantum (Container, Benutzer 1000)→ liest und schreibt →/srv/dateien

Was du brauchst

  • Einen Linux-Server mit Docker und dem Compose-Plugin. Ein Debian oder Ubuntu, ein LXC auf Proxmox, ein alter Büro-PC: alles recht. Prüfbefehle stehen gleich unten.
  • Einen Ordner mit Dateien, den Quantum zeigen soll. Nicht die Wurzel des Systems und nicht dein ganzes Home; einen Ordner, in dem ein versehentliches Löschen wehtut, aber nicht das System mitreißt.
  • Deine Benutzernummer. Der Container läuft als Benutzer 1000, das steht so in der Doku und im Dockerfile. Ist dein Server-Benutzer ebenfalls 1000 (bei der ersten angelegten Person auf Debian und Ubuntu die Regel), passt alles von allein. Ist er es nicht, kommt weiter unten der Handgriff dazu.
  • Einen freien Port, hier 8080. Meldet der Prüfbefehl einen Treffer, hilft der Beitrag zum belegten Port.
  • Ein Backup des Ordners. Quantum darf darin löschen, mit denselben Rechten wie du. Ich weiß, du hast eins. Prüf trotzdem, wann es zuletzt gelaufen ist.
So liest du diese Anleitung: Alles, was du selbst tun sollst, steht in einem farbigen Kasten. [ per klick ] heißt: Das erledigst du mit der Maus in einer Web-Oberfläche, hier die Oberfläche von FileBrowser Quantum. [ über die shell ] heißt: Den Befehl kopieren, ins Terminal einfügen, Enter. Stehen beide Kästen direkt untereinander, führen sie zum selben Ergebnis. Du gehst EINEN davon, nicht beide.

Die Voraussetzungen prüfst du auf dem Server, per SSH oder direkt an der Konsole:

docker --version
docker compose version
id -u
ss -tlnp | grep 8080
Docker version 28.3.2, build 578ccf6
Docker Compose version v2.39.1
1000

Die ersten beiden Zeilen dürfen andere Nummern tragen; Hauptsache, sie kommen. Die dritte ist deine Benutzernummer. Die vierte bleibt leer, wenn der Port frei ist. Fehlt Docker, hilft die Installationsseite in den Quellen; sie ist kurz.

Diese Werte benutze ich im ganzen Beitrag; ersetze sie durch deine:

  • IP-Adresse des Servers: 192.168.178.50
  • Ordner mit deinen Dateien: /srv/dateien
  • Projektordner für Quantum: ~/filebrowser (darin data/ für Konfiguration und Datenbank)
  • Port auf dem Server: 8080
  • Admin-Passwort: EinLangesPasswortHier (nur ein Platzhalter, bitte ersetzen)

Schritt 1: Ordner und config.yaml anlegen

Quantum will eine Konfigurationsdatei. Das Original kam ohne aus, und im Lemmy-Thread zum Abschied ist das der Hauptvorwurf von jello: Quantum habe den „just works"-Faktor verloren. Stimmt, und ich finde den Tausch trotzdem richtig, weil in dieser einen Datei genau das steht, was der Dienst sehen darf. Der Ordner data nimmt sie auf, und später legt Quantum dort auch Datenbank und Cache ab.

mkdir -p ~/filebrowser/data
cd ~/filebrowser
nano data/config.yaml

In den leeren Editor kommt dieser Inhalt; die Einrückung mit zwei Leerzeichen ist Teil der Syntax. Speichern mit Strg+O und Enter, schließen mit Strg+X:

server:
  cacheDir: /home/filebrowser/data/tmp
  sources:
    - path: /folder
      name: Dateien
      config:
        defaultEnabled: true

Drei Dinge stehen da. Der Cache landet im Ordner data, also auf deiner Platte statt im Container. Eine „Source" ist Quantums Wort für einen Ordner, den es zeigt; /folder ist der Pfad im Container, und welcher Ordner deines Servers dort erscheint, legt gleich die Compose-Datei fest. defaultEnabled heißt: Jeder Benutzer, den du anlegst, bekommt diese Source automatisch. Für einen Server mit dir als einzigem Benutzer ist das richtig; für eine Familie schaust du dir das in den Einstellungen am Ende noch einmal an. Ob die Datei da ist:

cat data/config.yaml

Zeigt der Befehl die sieben Zeilen, weiter.

Schritt 2: Die Compose-Datei

Die zweite Datei ist der Bauplan für den Container. Die Doku nennt sie docker-compose.yaml; Docker nimmt genauso compose.yaml, und die kürzere Form benutze ich hier. Der Inhalt folgt dem Beispiel aus der Quantum-Doku, mit drei Anpassungen: das stabile Image, Port 8080 nach außen und das Admin-Passwort als Umgebungsvariable.

nano compose.yaml
services:
  filebrowser:
    image: gtstef/filebrowser:stable
    container_name: filebrowser
    environment:
      - FILEBROWSER_ADMIN_PASSWORD=EinLangesPasswortHier
    volumes:
      - /srv/dateien:/folder
      - ./data:/home/filebrowser/data
    ports:
      - 8080:80
    restart: unless-stopped

Speichern, schließen. Die zwei Zeilen unter volumes sind die wichtigsten der Datei. Die erste hängt deinen Ordner als /folder in den Container, dort, wo die config.yaml ihn erwartet. Die zweite legt data mit Konfiguration, Datenbank und Cache neben die Compose-Datei; ohne sie wären Benutzer und Freigaben nach jedem Neubau des Containers weg. Der Port: Innen lauscht Quantum auf 80, außen nimmst du 8080, damit dir ein späterer Reverse Proxy nicht in die Quere kommt.

Das Passwort steht im Klartext in der Datei, und das ist Absicht. Die Doku zur Passwort-Anmeldung sagt, dass ein Passwort in der config.yaml bei jedem Start zurückgesetzt wird, und empfiehlt die Umgebungsvariable. Ohne beides startet Quantum mit admin/admin, und die Doku sagt das offen. Läuft sofort, mit dem Passwort, das jeder kennt: Das ist die Sorte Bequemlichkeit, die mich misstrauisch macht. Darum steht das Passwort in der Datei, bevor der Container zum ersten Mal läuft. Die Datei bleibt auf dem Server und wandert in kein Git und keinen Share.

Schritt 3: Starten und anmelden

docker compose up -d
docker compose ps
NAME          IMAGE                       COMMAND           SERVICE       CREATED          STATUS                    PORTS
filebrowser   gtstef/filebrowser:stable   "./filebrowser"   filebrowser   40 seconds ago   Up 39 seconds (healthy)   0.0.0.0:8080->80/tcp, [::]:8080->80/tcp

Der erste Aufruf lädt das Image, laut Doku rund 60 Megabyte samt ffmpeg für Video-Vorschauen. Das Wort healthy ist die Erfolgskontrolle: Das Image bringt eine Gesundheitsprüfung mit, die alle 30 Sekunden die Adresse /health im Container abfragt. In den ersten Sekunden steht dort health: starting; nach einer halben Minute noch einmal docker compose ps. Bleibt es bei unhealthy oder startet der Container immer wieder neu, zeigt docker compose logs den Grund, meist eine Einrückung in der config.yaml.

Jetzt der Browser:

Im Browser http://192.168.178.50:8080 öffnen. Auf der Anmeldeseite Benutzername admin und das Passwort aus der Compose-Datei eintragen. Danach zeigt die Oberfläche unter dem Namen Dateien den Inhalt von /srv/dateien.

Wenn dort deine Ordner stehen, hast du gerade einen archivierten Dienst durch einen gepflegten ersetzt, und zwar in zwei Dateien. Kurz stolz sein, dann weiter, denn fertig eingestellt ist er noch nicht.

Was du danach einstellst

Ein zweiter Benutzer ohne Admin-Rechte. Mit dem Admin-Konto arbeitest du nicht im Alltag; es legt Benutzer an und sonst nichts. In der Doku zur Benutzerverwaltung ist der Weg beschrieben:

Als admin angemeldet in die Einstellungen, dort User Management, dann Create User (Stand Quantum 1.5). Benutzername und Passwort vergeben, den Admin-Haken aus lassen, die Source Dateien zuweisen und speichern. Zum Testen abmelden und mit dem neuen Konto anmelden.

Mindestlänge für Passwörter. Quantum akzeptiert ab Werk fünf Zeichen. Das ist für einen Dienst, der Dateien löschen darf, zu wenig; die Doku zeigt die Stellschraube. Die vier Zeilen kommen ans Ende der config.yaml, wobei auth: ganz links steht, auf gleicher Höhe wie server:. Danach den Container neu starten, weil Quantum die Konfiguration nur beim Start liest:

nano data/config.yaml
auth:
  methods:
    password:
      minLength: 12
docker compose restart
docker compose ps

Steht wieder healthy, hat die Datei gepasst. Wer noch eine Stufe weiter will: Quantum kann Einmalcodes aus einer Authenticator-App. Dafür kommt laut Doku ein Geheimnis aus openssl rand -base64 32 als totpSecret unter auth:, und enforcedOtp: true macht die Codes für alle Passwort-Benutzer zur Pflicht. Für den Anfang reicht das lange Passwort; die Zwei-Faktor-Anmeldung ist ein eigener Handgriff, und ich würde sie nachziehen, sobald der Dienst von außen erreichbar ist.

Freigaben mit Ablaufdatum. Ein Link auf einen Ordner ist bequem und lebt ewig, wenn du nichts tust. Quantum bietet beim Erstellen einer Freigabe Passwort, Ablaufzeit und Download-Limit an; nimm mindestens das Ablaufdatum. Dass der Fix vom 04-09-2026 genau die Freigaben betraf, ist für mich der Grund, Quantum überhaupt aktuell zu halten: Das war ein moderater Fehler, gemeldet, gefixt, in beiden Linien. Beim Original hätte er ab jetzt einfach offen gestanden.

Nur von außen über einen Reverse Proxy. Port 8080 ins Internet freizugeben, würde ich nicht tun; die alten Maintainer haben es in ihrer Abschiedsnotiz genauso gesagt. Wenn der Dienst von unterwegs erreichbar sein soll, gehört ein Reverse Proxy mit TLS davor, und Quantum will dann in der config.yaml unter http: wissen, welchen Kopfzeilen es traut. Die Liste für 1.5.x steht in der HTTP-Doku in den Quellen; sie ist ein eigener Abschnitt und kommt in einen eigenen Beitrag.

Sichern und aktualisieren. Zwei Orte: Deine Dateien liegen in /srv/dateien und sind hoffentlich schon im Backup. Alles, was Quantum selbst weiß, liegt in ~/filebrowser/data: config.yaml, die Datenbank database.db mit Benutzern, Freigaben und Einstellungen. Dieser Ordner gehört ins Backup, sonst legst du nach einem Plattentod jeden Benutzer neu an. Updates innerhalb der stabilen Linie sind zwei Befehle:

docker compose pull
docker compose up -d

Das Tag stable bleibt dabei in der 1.5-Linie. Auf beta oder später auf 2.0 wechselst du bewusst und mit der Migrationsanleitung in der Hand, nicht per pull.

Wo es in den Issues und im Thread hakt

„permission denied" beim Hochladen oder Anlegen. Der Klassiker bei Diensten, die als fester Benutzer laufen. Quantum schreibt als Nummer 1000; gehört /srv/dateien einem anderen Benutzer, darf es nur lesen. Prüfen kannst du das mit Zahlen statt Namen:

ls -ln /srv
drwxr-xr-x 5 1000 1000 4096  9. Sep 20:14 dateien

Steht in der dritten Spalte eine andere Zahl als 1000, hat Quantum keine Schreibrechte. Gehört der Ordner nur diesem Dienst, ist sudo chown -R 1000:1000 /srv/dateien der kurze Weg. Teilen sich mehrere Dienste den Ordner, ist der Besitzerwechsel keine gute Idee, weil dann ein anderer Dienst nicht mehr schreiben darf; dann bleibt die Gruppe, in der beide sind, und Schreibrecht für sie. Was ich nicht tun würde: den Container über user: als andere Nummer laufen lassen. Chocolate-Banana hat in Issue 1038 beschrieben, was dann passiert, Ordner-Downloads und große Uploads brechen mit Fehler 500 ab.

„mkdir /home/fb_users: permission denied". quadraxis33 in Issue 2506, mit dem stabilen Image. Der Fehler kommt, wenn die Konfiguration Quantum anweist, für jeden Benutzer einen eigenen Ordner anzulegen, der Zielpfad aber im Container liegt und nicht auf deiner Platte. Für die Konfiguration oben gilt das nicht. Wenn du später die Option createUserDir aus der Sources-Doku benutzt, muss der Pfad unter einem Volume liegen.

Große Uploads brechen nach zwei Stunden ab. Das größte Ärgernis von jello im Lemmy-Thread, bei Dateien um fünf Gigabyte. captcha_incorrect hat dort die Lösung genannt: Das Anmelde-Token der Oberfläche läuft laut Standardkonfiguration nach zwei Stunden ab, und mit ihm der Upload. Die Einstellung heißt tokenExpirationHours unter auth: in der config.yaml; ein höherer Wert hilft, kostet aber längere Sitzungen auf fremden Geräten. Ich würde erst prüfen, ob der Server über die Zeit nicht schneller ist, und den Wert nur anheben, wenn es wirklich an der Uhr liegt.

„bind: permission denied" beim Start. LFrank2021 und baishikele001 haben das in Issue 2329 und 2598 gemeldet, beide ohne Docker beziehungsweise mit Podman. Ports unter 1024 darf ein normaler Benutzer nicht öffnen; der Container läuft als Nummer 1000 und lauscht auf 80. Bei Docker mit Root-Rechten läuft das durch. Auf Podman und anderen Engines ohne Root steht in der Docker-Doku von Quantum der Zusatz cap_add: [NET_BIND_SERVICE] für die Compose-Datei.

Umzug vom alten File Browser. Die Migrationsseite in der Doku übersetzt die alten Startparameter in die neue YAML: --root wird zur ersten Source, --port und --baseurl wandern unter http:. Was sie nicht verspricht, ist die Übernahme der alten Datenbank mit Benutzern und Freigaben; die Seite spricht nur von der Konfiguration. Ich würde Quantum daneben aufsetzen, die drei Benutzer neu anlegen und den alten Container erst stoppen, wenn der neue läuft. Terminal und Runner gibt es in Quantum nicht mehr, und wer sie gebraucht hat, braucht ein anderes Werkzeug. Für die meisten war das Terminal ohnehin ein offenes Fenster, das sie nie benutzt haben.

Einsteigen ja, aber in die stabile Linie

Für einen Dateimanager im Browser würde ich heute Quantum nehmen. Zwei Dateien, ein Befehl, und der Dienst tut, was das Original konnte, ohne das, was am Original gefährlich war. Die Gegenrechnung kennt der Lemmy-Thread: Es ist nicht mehr der Dienst, der ohne Konfiguration läuft, und die Doku ist auf 2.0 ausgerichtet, während du 1.5 installierst. Beides kann man aushalten. Das Beta-Tag hätte ich gern empfohlen, weil die neue Rechteverwaltung pro Source ein echter Fortschritt ist, aber Beweis vor Applaus: Erst wenn 2.0 ohne das Wort beta erscheint, ist es ein Abend für die Migration.

Lief bei dir noch das alte File Browser, und was hast du stattdessen eingesetzt? Und falls Quantum: Hat die Konfigurationsdatei beim ersten Mal gepasst, oder hat auch dich eine Einrückung zehn Minuten gekostet? Schreib's in die Kommentare, ich lese mit.

Wer den Dienst im nächsten Schritt von unterwegs erreichen will, findet die Grundlage dafür im Beitrag zum Reverse Proxy; die Anleitung mit Quantum dahinter ist vorgemerkt.

Quellen