File Browser zelf hosten in 2026: volumes, accounts en veilig delen

Beschouw File Browser als een klein systeem, niet als een Docker-image. Het doel voor gebruikers van File Browser is duidelijk: een webgebaseerde file manager voor een gekoppeld volume. De deployment is pas geschikt wanneer je een beperkte gebruiker kunt aanmaken, een bestand kunt uploaden en hernoemen, tekst kunt bewerken, een share kunt genereren en kunt bevestigen dat de gebruiker niet buiten de toegewezen root kan komen.

Dat onderscheid brengt de foutmodus aan het licht die operators na lokale tests tegenkomen: de gemounte bestanden gebruiken permissies op de host die de container niet kan lezen. Het maakt het back-up- en upgradeplan bovendien specifiek genoeg om te testen.

Zoek elke persistente byte in File Browser

Een container-image kan opnieuw worden gedownload; de aangeboden bestanden en de File Browser-database en -instellingen niet. Mount /srv vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Controleer de effectieve mount in plaats van te vertrouwen op een Compose-bestandsnaam, en controleer of de runtime user kan schrijven op de plek die File Browser verwacht.

Kies een bewaartermijn en een off-host-bestemming en oefen vervolgens het herstel zonder productie aan te raken. De oefening is pas geslaagd wanneer aangeboden bestanden, gebruikers, scopes, shares en instellingen zijn teruggekeerd en een beperkte account binnen de toegewezen grenzen blijft. Combineer voor state die door een database wordt beheerd storage snapshots met application-consistente exports, zoals beschreven in point-in-time recovery versus snapshots.

Start de eerste productieachtige instance

Houd de eerste File Browser-aanroep reproduceerbaar genoeg om in een pull request te kunnen reviewen.

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

Vertrouw niet op latest zodra er echte data aanwezig is. Leg de werkende digest, container user en mount ownership vast. Volg het application log tijdens een volledige test — maak een beperkte gebruiker aan, upload en hernoem een bestand, bewerk tekst, genereer een share en bevestig dat de gebruiker niet buiten de toegewezen root kan komen — en noteer eventuele migrations voordat je de route achter production traffic plaatst.

Baken de File Browser-runtime af

De gezondheid van het proces en die van het product zijn bij File Browser twee verschillende zaken. Poort 80 kan antwoord geven terwijl de transactie voor de gebruiker nog steeds mislukt. De lokale runtime vereist afzonderlijke persistente paden voor de database en instellingen. Valideer dit met de acceptance workload; een idle health check kan niet aantonen dat de resource toereikend is.

Gebruik deze readiness-oefening na belangrijke configuratiewijzigingen: maak een beperkte gebruiker aan, upload en hernoem een bestand, bewerk tekst, genereer een share en bevestig dat de gebruiker niet buiten de toegewezen root kan komen. Houd dure externe checks buiten liveness probes, zodat een storing bij een provider geen restart loop veroorzaakt. Richt capacity-planning op onderliggende disk throughput, uploadgrootte, gelijktijdige downloads en het aantal directories. Dat sluit beter aan op de werkelijke belasting van File Browser dan page requests.

Maak de publieke origin ondubbelzinnig

Stel voor File Browser één HTTPS-hostname beschikbaar en houd raw port 80 privé. Publiceer de UI via HTTPS, maar beperk de served root zorgvuldig. Zo voorkom je dat browsers en API-clients twee concurrerende adressen leren kennen.

Voer vanaf een clean client de bekende, geslaagde transactie uit en inspecteer het eerste request dat faalt. Gebruik de custom-domain guide wanneer DNS of TLS niet klopt. Beschouw “de gemounte bestanden gebruiken permissies op de host die de container niet kan lezen” als een afzonderlijke application-diagnose zodra de route is gevalideerd.

De File Browser-release gate

Maak een kleine, disposable File Browser-fixture en bewaar die voor elke release. De fixture moet de echte workflow uitvoeren: maak een beperkte gebruiker aan, upload en hernoem een bestand, bewerk tekst, genereer een share en bevestig dat de gebruiker niet buiten de toegewezen root kan komen. Leg de image digest, externe hostname, dependency address en het verwachte resultaat vast, zodat een volgende operator de test kan herhalen zonder deze handleiding te hoeven interpreteren.

Voer de fixture drie keer uit. Gebruik eerst de verse deployment. Vervang daarna de container zonder persistente state aan te raken. Herstel ten slotte de back-up in een lege omgeving. De derde run is pas geslaagd wanneer aangeboden bestanden, gebruikers, scopes, shares en instellingen zijn teruggekeerd en een beperkte account binnen de toegewezen grenzen blijft. Leg tijdens elke run latency en resourcegebruik vast rond onderliggende disk throughput, uploadgrootte, gelijktijdige downloads en het aantal directories. Dit wordt de baseline voor alerts, in plaats van een willekeurig CPU-percentage.

Test ten slotte bewust het negatieve pad: stuur onschadelijke input in de buurt van de resource- of formatlimiet die bij deze grens hoort: de gemounte bestanden gebruiken permissies op de host die de container niet kan lezen. Bevestig dat File Browser zichtbaar faalt zonder state te corrumperen, herstel de juiste situatie en herhaal de geslaagde transactie. Een releaseverslag met deze vier uitkomsten levert sterker bewijs dan screenshots van een dashboard of een eenmalige curl-respons.

Capacity- en upgradechecks

Een idle health check zegt weinig over File Browser. Houd onderliggende disk throughput, uploadgrootte, gelijktijdige downloads en het aantal directories in de gaten en alert op het symptoom dat gebruikers ervaren: het mislukken van de actie “maak een beperkte gebruiker aan, upload en hernoem een bestand, bewerk tekst, genereer een share en bevestig dat de gebruiker niet buiten de toegewezen root kan komen”. Houd liveness lokaal en goedkoop; laat readiness migrations of initialisatie rapporteren zonder een restart storm te veroorzaken.

Het risicovolle onderdeel van een upgrade is dat migrations van de File Browser-database en -instellingen belangrijk zijn, ook al staan de aangeboden bestanden op een afzonderlijke mount. Lees de release notes, maak een snapshot van de state, deploy de doelversie tegen een herstelde kopie en herhaal de acceptance action. Als de gemounte bestanden permissies op de host gebruiken die de container niet kan lezen, koppel dan het client request aan het eerste relevante application log in plaats van blind state te verwijderen of redirects toe te voegen.

Beperk de bevoegdheden van File Browser

Bootstrap-credentials zijn tijdelijk; het trustmodel is permanent. Let bij File Browser op het serveren van / of een secrets-directory in plaats van een dedicated share. Serveer een dedicated directory in plaats van de host root en geef elk account de kleinst mogelijke file scope die het nodig heeft.

File Browser heeft in deze baseline geen verplichte bootstrap secret. Beveilig in plaats daarvan het daadwerkelijke administrator-account of upstream authentication. Draai de image zonder onnodige Linux capabilities en stel alleen de publieke application route beschikbaar. Houd administratoractiviteit zichtbaar zonder secret values vast te leggen.

Gebruik Dockup voor de platformlaag

Voor File Browser is Dockup vooral nuttig op de grens tussen een image en een durable service. Het houdt de route naar 80, TLS, secret values en storage gekoppeld tijdens het vervangen van containers, ongeacht of de compute van Dockup of van je gekoppelde server komt.

Vul dit aan met application knowledge: publiceer de UI via HTTPS, maar beperk de served root zorgvuldig; bevestig de lokale vereiste — een afzonderlijk persistent pad voor de database en instellingen — en voer deze verificatie uit: maak een beperkte gebruiker aan, upload en hernoem een bestand, bewerk tekst, genereer een share en bevestig dat de gebruiker niet buiten de toegewezen root kan komen. Bewaar het resultaat als deployment check, zodat de volgende image-update wordt beoordeeld op gedrag en niet op de containerstatus.

Veelgestelde vragen

Wat heeft File Browser nodig voor een productie-deployment?

Routeer de File Browser-container op poort 80 via één HTTPS-origin. De lokale runtime vereist een afzonderlijk persistent pad voor de database en instellingen. Markeer File Browser pas als klaar wanneer je een beperkte gebruiker kunt aanmaken, een bestand kunt uploaden en hernoemen, tekst kunt bewerken, een share kunt genereren en kunt bevestigen dat de gebruiker niet buiten de toegewezen root kan komen.

Welke File Browser-data hoort in een back-up?

Maak /srv persistent en neem de aangeboden bestanden plus de File Browser-database en -instellingen op in hetzelfde recovery manifest. Een clean File Browser-restore is pas geslaagd wanneer aangeboden bestanden, gebruikers, scopes, shares en instellingen zijn teruggekeerd en een beperkte account binnen de toegewezen grenzen blijft.

Heeft File Browser HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke File Browser-origin en houd poort 80 op de interne route. Pas de File Browser-instelling correct toe: publiceer de UI via HTTPS, maar beperk de served root zorgvuldig. Voor File Browser beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het voor consistent gedrag van clients die gevoelig zijn voor de origin.

Hoe moet een File Browser-upgrade worden getest?

Herstel de huidige File Browser-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptance transaction. Let hier extra op, omdat migrations van de File Browser-database en -instellingen belangrijk zijn, ook al staan de aangeboden bestanden op een afzonderlijke mount. Bewaar de vorige File Browser-image totdat de grenzen van data migration en rollback duidelijk zijn.