FileBrowser Quantum 2.0 adds activity logs and per-source permissions
The FileBrowser Quantum fork reached 2.0 stable on October 9, 2026 with an activity log, per-storage-source permissions, and a BoltDB-to-SQLite migration, followed on October 13 by a fix for two security flaws. Prepare a real migration procedure before upgrading your 1.x instances.
October 9, 2026. FileBrowser Quantum, the fork of File Browser that became the default migration path after the original was archived, ships its 2.0 stable. October 9, 2026. It introduces an activity log and per-storage-source permissions, while replacing BoltDB with SQLite. October 13, 2026. Version 2.0.1 patches two security flaws, including a directory traversal. Why it matters: the fork we recommended after File Browser died is delivering on its promise, but its migration is more than a docker compose pull — and 2.0.1 already proves it patches what the original never will again.
The fork that had to succeed File Browser
In September 2026, File Browser — the self-hosted web file manager with 36,000 GitHub stars — was archived after its final v2.63.23 release. We recommended FileBrowser Quantum as the least painful migration path: a fork that keeps database compatibility and patches known vulnerabilities. The 2.0 release of October 2026 is the first milestone that lets us check whether that promise holds.
It holds, and it goes further. 2.0 is not a bare security port: it is a real functional evolution aimed at the two most glaring gaps in the original for multi-user servers — traceability and fine-grained permissions. That is exactly what you expect from a fork that wants to be more than a survival patch.
An activity log that answers “who touched what”
The most anticipated addition is the Activity Viewer, a built-in activity log. It records uploads, downloads, deletions, and other supported operations, along with account activity: logins and permission changes. Logs are filterable and exportable as CSV, and history is kept for 30 days by default, a period the administrator can adjust.
For a shared server — a family storing photos, a small team exchanging documents — this changes the nature of the tool. Until now, the answer to “this file disappeared, who deleted it?” was silence. With the Activity Viewer, it becomes a query in the interface. That is the kind of feature that separates a trusted tool from a mere file viewer.
Its limits must be understood, though. The log only sees what passes through FileBrowser Quantum itself: a change made over SSH or by another application will not appear, and file previews and WebDAV reads are not recorded either. For an administrator, that means the Activity Viewer documents interface usage, not the full activity of the volume — a boundary to keep in mind before relying on it for an audit.
Per-source permissions, and the end of “all or nothing”
The second structural change concerns permissions. Before, rights were mostly managed at the global user level. 2.0 assigns them separately for each storage source, with independent controls for viewing, downloading, and modifying. In practice, one account can browse family photos without being able to delete them, and another can drop documents into a specific directory without access to the rest.
That is real progress for multi-user setups. The split view / download / modify granularity enables scenarios that were previously impossible or worked around: read-only sharing, upload-without-delete, access limited to a single tree. The useful nuance, flagged by the developers, is that allowing someone to view a document does not guarantee the content cannot be captured by other means — a screenshot is enough. Permissions protect the interface, not the information itself.
The BoltDB-to-SQLite migration is a real project
The part that deserves the most attention is operational, not functional. FileBrowser Quantum 2.0 replaces BoltDB with SQLite and reorganizes its configuration structure. For a 1.x installation, a plain docker compose pull is not enough: the migration requires backing up the old database, converting the configuration, then letting the application import existing accounts into SQLite.
Some settings have moved too. HTTP configuration now lives in a dedicated http section, and the database environment variable changes from FILEBROWSER_DATABASE to FILEBROWSER_DATABASE_PATH. Existing permissions should be reviewed afterward, especially when users access multiple sources. The official migration guide covers the process — but the rule of caution stands: verify your backups are restorable before upgrading. A backup that does not restore does not protect.
The lesson echoes a broader self-hosting point: a project’s maintenance status is a security datum in its own right. File Browser died without a safety net; FileBrowser Quantum lives, but its life now involves schema migrations that must be planned like any production operation.
2.0.1 proves the fork patches
Four days after 2.0, version 2.0.1 shipped on October 13 to fix two security vulnerabilities. One involved accounts created with crafted usernames containing .., which could allow access outside their assigned directory — a classic directory traversal. The other involved a session token issue.
That rapid fix is exactly the demonstration that the fork does the job it was chosen for. Where an archived File Browser would have fixed nothing, FileBrowser Quantum ships a security patch four days after its major release. For anyone who migrated after the September archive, it confirms the choice was right; for anyone still lingering on the original, it is one more reason to move.
The fork is now the upstream
There is a broader lesson in this release for anyone who runs self-hosted software. When File Browser was archived, the community’s options were to freeze on a dead codebase or bet on a fork whose long-term commitment was unproven. FileBrowser Quantum 2.0 — with its schema migration, its activity viewer, and a security patch shipped four days after a major release — is evidence that the fork has moved from “survival mode” into “maintenance with a roadmap.”
That shift matters more than any single feature. A fork that only mirrors security fixes stays a shadow of the original; a fork that reorganizes its database and rethinks its permission model is building for the long term. For operators, that is the difference between migrating twice and migrating once.
The practical takeaway is to treat maintenance signals as part of due diligence. Before adopting any self-hosted tool, check not just the last release date but the shape of the release: are there schema migrations, changelogs, security advisories? FileBrowser Quantum now ticks all three boxes, which is precisely why it has earned the role the community assigned it.
Verdict
If you are still on archived File Browser 1.x, migrate to FileBrowser Quantum following the official guide: back up the BoltDB database, convert the configuration, import accounts into SQLite, then re-check per-source permissions — and validate that your backup restores before anything else. If you are already on Quantum 1.x, plan the 2.0 migration as a dedicated operation, not a routine update: the BoltDB-to-SQLite switch and the moved configuration variables deserve their own window. If you are starting a new self-hosted file-management project, begin directly on 2.0 — activity logs and per-source permissions are now the baseline any multi-user tool should provide. The signal of 2.0 is clear: the fork is not just surviving, it is catching up on what the original lacked.