FileBrowser Quantum 2.0 ajoute les journaux d’activité et les permissions par source
Le fork FileBrowser Quantum passe en 2.0 stable le 9 octobre 2026 avec un journal d’activité, des permissions par source de stockage et une migration de BoltDB vers SQLite, suivie le 13 octobre d’un correctif pour deux failles de sécurité. Préparez une vraie procédure de migration avant de mettre à jour vos instances 1.x.
9 octobre 2026. FileBrowser Quantum, le fork de File Browser devenu la voie de migration par défaut depuis l’archivage de l’original, publie sa version 2.0 stable. 9 octobre 2026. Elle introduit un journal d’activité et des permissions par source de stockage, tout en remplaçant la base BoltDB par SQLite. 13 octobre 2026. La 2.0.1 corrige deux failles de sécurité, dont une traversée de répertoire. Pourquoi c’est important : le fork recommandé après la mort de File Browser tient ses promesses, mais sa migration ne se résume pas à un docker compose pull — et la 2.0.1 prouve déjà qu’il patche ce que l’original ne patchera plus.
Le fork qui devait succéder à File Browser
En septembre 2026, File Browser — le gestionnaire de fichiers web auto-hébergé aux 36 000 étoiles GitHub — était archivé après sa dernière version v2.63.23. Nous recommandions alors FileBrowser Quantum comme la voie de migration la moins douloureuse : un fork qui conserve la compatibilité de base de données et patchait les vulnérabilités connues. La 2.0 de octobre 2026 est le premier jalon qui permet de vérifier si cette promesse tient.
Elle tient, et elle va plus loin. La 2.0 n’est pas un simple port de sécurité : c’est une vraie évolution fonctionnelle qui s’attaque aux deux manques les plus criants de l’original pour les serveurs multi-utilisateurs — la traçabilité et la finesse des permissions. C’est précisément ce qu’on attend d’un fork qui veut être plus qu’un correctif de survie.
Un journal d’activité qui répond à la question « qui a touché quoi »
La nouveauté la plus attendue est l’Activity Viewer, un journal d’activité intégré. Il enregistre les uploads, les téléchargements, les suppressions et les autres opérations supportées, ainsi que l’activité liée aux comptes : connexions et changements de permissions. Les journaux sont filtrables et exportables en CSV, et l’historique est conservé 30 jours par défaut, une durée ajustable par l’administrateur.
Pour un serveur partagé — la famille qui stocke ses photos, la petite équipe qui échange des documents — c’est un changement de nature. Jusqu’ici, la réponse à « ce fichier a disparu, qui l’a supprimé ? » était le silence. Avec l’Activity Viewer, elle devient une requête dans l’interface. C’est le genre de fonctionnalité qui distingue un outil de confiance d’un simple visualiseur de fichiers.
Il faut néanmoins connaître ses limites. Le journal ne voit que ce qui passe par FileBrowser Quantum lui-même : une modification faite en SSH ou par une autre application n’apparaîtra pas, et les aperçus de fichiers comme les lectures WebDAV ne sont pas enregistrés. Pour un administrateur, cela signifie que l’Activity Viewer documente l’usage de l’interface, pas l’intégralité de l’activité du volume — une frontière à garder en tête avant de s’appuyer dessus pour un audit.
Des permissions par source, et la fin du « tout ou rien »
La seconde nouveauté structurelle concerne les permissions. Avant, les droits se géraient surtout au niveau global de l’utilisateur. La 2.0 les assigne séparément pour chaque source de stockage, avec des contrôles indépendants pour voir, télécharger et modifier. Concrètement, un compte peut parcourir les photos de famille sans pouvoir les supprimer, et un autre peut déposer des documents dans un dossier précis sans accéder au reste.
C’est un vrai progrès pour le multi-utilisateur. La granularité voir / télécharger / modifier séparés permet des scénarios qui étaient impossibles ou contournés avant : le partage en lecture seule, le dépôt sans suppression, l’accès limité à une seule arborescence. La nuance utile, rappelée par les développeurs, est que autoriser la visualisation ne garantit pas que le contenu ne puisse pas être capturé par d’autres moyens — une capture d’écran suffit. La permission protège l’interface, pas l’information elle-même.
La migration BoltDB vers SQLite, un vrai chantier
La partie qui demande le plus d’attention n’est pas fonctionnelle, mais opérationnelle. FileBrowser Quantum 2.0 remplace BoltDB par SQLite et réorganise sa structure de configuration. Pour une installation 1.x, un simple docker compose pull ne suffit pas : la migration exige de sauvegarder l’ancienne base, de convertir la configuration, puis de laisser l’application importer les comptes existants dans SQLite.
Des réglages ont aussi changé d’endroit. La configuration HTTP passe dans une section dédiée http, et la variable d’environnement de la base change de FILEBROWSER_DATABASE à FILEBROWSER_DATABASE_PATH. Les permissions existantes doivent être revues après coup, en particulier quand des utilisateurs accèdent à plusieurs sources. Le guide de migration officiel couvre le processus — mais la règle de prudence reste : vérifiez que vos sauvegardes sont restaurables avant de mettre à jour. Un backup qui ne restaure pas ne protège pas.
La leçon rejoint un constat plus large du self-hosting : la maintenance d’un projet est une donnée de sécurité à part entière. File Browser est mort sans filet ; FileBrowser Quantum vit, mais sa vie implique désormais des migrations de schéma qu’il faut planifier comme n’importe quelle opération de production.
La 2.0.1 prouve que le fork patche
Quatre jours après la 2.0, la 2.0.1 est sortie le 13 octobre pour corriger deux vulnérabilités de sécurité. L’une concernait des comptes créés avec des noms d’utilisateur forgés contenant .., qui pouvaient permettre d’accéder hors de leur répertoire assigné — une traversée de répertoire classique. L’autre concernait un problème de jeton de session.
Ce correctif rapide est précisément la démonstration que le fork remplit le rôle pour lequel il a été choisi. Là où File Browser archivé n’aurait plus rien corrigé, FileBrowser Quantum publie un patch de sécurité quatre jours après sa version majeure. Pour qui a migré après l’archivage de septembre, c’est la confirmation que le choix était le bon ; pour qui traîne encore sur l’original, c’est un argument de plus pour bouger.
Le fork est devenu l’amont
Cette release porte une leçon plus large pour quiconque exploite du logiciel auto-hébergé. Quand File Browser a été archivé, la communauté avait deux options : geler sur une base morte, ou parier sur un fork dont l’engagement à long terme restait à prouver. FileBrowser Quantum 2.0 — avec sa migration de schéma, son journal d’activité et un correctif de sécurité publié quatre jours après une version majeure — démontre que le fork est passé du mode survie à la maintenance avec feuille de route.
Ce basculement compte plus que n’importe quelle fonctionnalité isolée. Un fork qui se contente de répliquer les correctifs de sécurité reste l’ombre de l’original ; un fork qui réorganise sa base et repense son modèle de permissions construit pour durer. Pour un opérateur, c’est la différence entre migrer deux fois et migrer une seule.
La conséquence pratique est de traiter les signaux de maintenance comme un critère de choix. Avant d’adopter un outil auto-hébergé, ne regardez pas seulement la date de la dernière version, mais la forme des releases : y a-t-il des migrations de schéma, un journal des changements, des avis de sécurité ? FileBrowser Quantum coche désormais les trois cases — c’est précisément ce qui lui a valu le rôle que la communauté lui a confié.
Verdict
Si vous êtes encore sur File Browser 1.x archivé, migrez vers FileBrowser Quantum en suivant le guide officiel : sauvegardez la base BoltDB, convertissez la configuration, importez les comptes dans SQLite, puis revérifiez les permissions par source — et validez que votre sauvegarde se restaure avant toute chose. Si vous êtes déjà sur Quantum 1.x, planifiez la migration 2.0 comme une opération à part entière, pas comme une mise à jour de routine : le passage BoltDB vers SQLite et le déplacement des variables de configuration demandent une fenêtre dédiée. Si vous démarrez un nouveau projet de gestion de fichiers auto-hébergé, partez directement sur la 2.0 — les journaux d’activité et les permissions par source sont désormais la norme qu’un outil multi-utilisateur doit fournir. Le signal de la 2.0 est clair : le fork ne se contente pas de survivre, il rattrape ce qui manquait à l’original.