Sådan self-hoster du File Browser i 2026: Volumes, konti og sikker deling

Betragt File Browser som et lille system, ikke som et Docker-image. Det brugerrettede mål med File Browser er klart: en webbaseret file manager til et tilknyttet volume. Installationen er dog kun acceptabel, når du kan oprette en begrænset bruger, uploade og omdøbe en fil, redigere tekst, generere et share og bekræfte, at brugeren ikke kan komme uden for den tildelte root.

Denne skelnen afslører den fejltilstand, operatører møder efter lokal test: De monterede filer bruger host-tilladelser, som containeren ikke kan læse. Den gør også backup- og upgrade-planen tilstrækkeligt konkret til, at den kan testes.

Find alle permanente bytes i File Browser

Et container-image kan downloades igen, men de viste filer samt File Browser-databasen og -indstillingerne kan ikke. Mount /srv før bootstrap, skriv harmløse eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. Kontrollér det effektive mount i stedet for at stole på et Compose-filnavn, og kontrollér, at runtime-brugeren kan skrive, hvor File Browser forventer det.

Vælg retention og en destination uden for hosten, og øv derefter recovery uden at røre produktionen. Øvelsen er kun godkendt, når de viste filer, brugere, scopes, shares og indstillingerne er gendannet, og en begrænset konto stadig er afgrænset. For databasebaseret state bør du kombinere storage snapshots med application-consistent exports som beskrevet i point-in-time recovery versus snapshots.

Kør den første produktionslignende instans

Hold den første File Browser-invocation tilstrækkeligt reproducerbar til, at den kan gennemgås i en pull request.

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

Stol ikke på latest, når der først findes rigtige data. Gem det fungerende digest, container-brugeren og mount-ejerskabet. Følg applikationsloggen gennem en komplet test — opret en begrænset bruger, upload og omdøb en fil, rediger tekst, generér et share, og bekræft, at brugeren ikke kan komme uden for den tildelte root — og notér eventuelle migrations, før du sender routen bag produktionstrafik.

Afgræns File Browser-runtime

Processtatus og produktstatus er to forskellige ting for File Browser. Port 80 kan svare, selvom den brugerrettede transaktion stadig fejler. Det lokale runtime-krav er en separat persistent sti til databasen og indstillingerne. Validér det med den faktiske acceptance workload; et idle health check kan ikke bevise, at ressourcen er tilstrækkelig.

Brug denne readiness-øvelse efter væsentlige konfigurationsændringer: Opret en begrænset bruger, upload og omdøb en fil, redigér tekst, generér et share, og bekræft, at brugeren ikke kan komme uden for den tildelte root. Hold dyre eksterne checks ude af liveness probes, så et provider-nedbrud ikke udløser en restart loop. Kapacitetsarbejdet bør følge den underliggende disk-throughput, uploadstørrelsen, antallet af samtidige downloads og antallet af mapper. Det ligger tættere på File Browsers reelle belastning end page requests.

Gør den offentlige origin entydig

Eksponér ét HTTPS-hostnavn til File Browser, og hold rå port 80 privat. Udgiv UI'et over HTTPS, men afgræns den viste root omhyggeligt. Det forhindrer browsere og API-klienter i at lære to konkurrerende adresser.

Kør den kendte transaktion fra en ren klient, og undersøg den første request, der fejler. Brug guiden til custom domains, når DNS eller TLS er forkert. Behandl “de monterede filer bruger host-tilladelser, som containeren ikke kan læse” som en separat applikationsdiagnose, når routen er dokumenteret korrekt.

File Browser-release-gaten

Opret en lille, midlertidig File Browser-fixture, og behold den til hver release. Fixturen bør afprøve det reelle workflow: Opret en begrænset bruger, upload og omdøb en fil, redigér tekst, generér et share, og bekræft, at brugeren ikke kan komme uden for den tildelte root. Registrér image-digestet, det eksterne hostname, dependency-adressen og det forventede resultat, så den næste operatør kan gentage testen uden at skulle fortolke denne guide.

Kør fixturen tre gange. Brug først den friske installation. Erstat derefter containeren uden at røre permanent state. Gendan til sidst backup'en i et tomt miljø. Den tredje kørsel er kun godkendt, når de viste filer, brugere, scopes, shares og indstillingerne er gendannet, og en begrænset konto stadig er afgrænset. Under hver kørsel skal du registrere latency og ressourceforbrug omkring den underliggende disk-throughput, uploadstørrelsen, antallet af samtidige downloads og antallet af mapper. Det bliver baseline for alerts i stedet for en vilkårlig CPU-procent.

Test til sidst den negative sti med vilje: Send harmløst input tæt på den ressource- eller formatgrænse, der er knyttet til denne grænse: De monterede filer bruger host-tilladelser, som containeren ikke kan læse. Bekræft, at File Browser fejler synligt uden at korrumpere state, genskab den korrekte tilstand, og gentag den vellykkede transaktion. En release-record med disse fire resultater er stærkere dokumentation end screenshots af et dashboard eller et enkeltstående curl-svar.

Kapacitets- og upgrade-checks

Et idle health check siger ikke meget om File Browser. Overvåg den underliggende disk-throughput, uploadstørrelsen, antallet af samtidige downloads og antallet af mapper, og opret derefter alerts på det symptom, brugerne oplever: at handlingen “opret en begrænset bruger, upload og omdøb en fil, redigér tekst, generér et share, og bekræft, at brugeren ikke kan komme uden for den tildelte root” fejler. Hold liveness lokal og billig; lad readiness rapportere migrations eller initialisering uden at forårsage en restart storm.

Det risikable område ved en upgrade er, at File Browser-database- og settings-migrations er vigtige, selvom de viste filer ligger på et separat mount. Læs release notes, tag et snapshot af state, deploy målversionen mod en gendannet kopi, og gentag acceptance-handlingen. Hvis de monterede filer bruger host-tilladelser, som containeren ikke kan læse, skal du sammenholde klientens request med den første relevante applikationslog i stedet for blindt at slette state eller tilføje redirects.

Begræns de rettigheder, File Browser har

Bootstrap-credentials er midlertidige; trust-modellen er permanent. Med File Browser skal du være opmærksom på, om du serverer / eller en secrets-mappe i stedet for et dedikeret share. Servér en dedikeret mappe i stedet for hostens root, og giv hver konto det smallest mulige file scope, den har brug for.

File Browser har ingen obligatorisk bootstrap-secret i denne baseline; beskyt i stedet den faktiske administrator-konto eller upstream authentication. Kør imaget uden unødvendige Linux capabilities, og eksponér kun den offentlige applikationsroute. Sørg for, at administratoraktivitet er synlig, uden at secret values bliver logget.

Brug Dockup til platformlaget

For File Browser er Dockup mest nyttigt ved grænsen mellem et image og en permanent service. Det holder routen til port 80, TLS, secret values og storage tilknyttet på tværs af containerudskiftninger, uanset om compute leveres af Dockup eller af din tilknyttede server.

Afslut med applikationsspecifik viden: Udgiv UI'et over HTTPS, men afgræns den viste root omhyggeligt; bekræft det lokale krav — en separat persistent sti til databasen og indstillingerne; og kør denne verifikation: Opret en begrænset bruger, upload og omdøb en fil, redigér tekst, generér et share, og bekræft, at brugeren ikke kan komme uden for den tildelte root. Gem resultatet som et deployment-check, så den næste image-opdatering vurderes ud fra adfærd og ikke containerstatus.

Ofte stillede spørgsmål

Hvad har File Browser brug for i en produktionsinstallation?

Route File Browser-containeren på port 80 gennem én HTTPS-origin. Det lokale runtime-krav er en separat persistent sti til databasen og indstillingerne. Kald ikke File Browser klar, før du kan oprette en begrænset bruger, uploade og omdøbe en fil, redigere tekst, generere et share og bekræfte, at brugeren ikke kan komme uden for den tildelte root.

Hvilke File Browser-data hører hjemme i en backup?

Gør /srv persistent, og inkludér de viste filer samt File Browser-databasen og -indstillingerne i det samme recovery-manifest. En ren File Browser-restore er kun godkendt, når de viste filer, brugere, scopes, shares og indstillingerne er gendannet, og en begrænset konto stadig er afgrænset.

Kræver File Browser HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige File Browser-origin, og behold port 80 på den interne route. Anvend File Browser-indstillingen korrekt: Udgiv UI'et over HTTPS, men afgræns den viste root omhyggeligt. For File Browser beskytter HTTPS credentials eller brugerindhold under transport og sørger for, at origin-følsom klientadfærd forbliver konsistent.

Hvordan bør en File Browser-upgrade testes?

Gendan den aktuelle File Browser-state i en isoleret installation, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi File Browser-database- og settings-migrations er vigtige, selvom de viste filer ligger på et separat mount. Behold det tidligere File Browser-image, indtil grænsen for datamigration og rollback er forstået.