Published: October 8, 2025
Last updated: July 24, 2026
Suggest an edit

Access control in FileBrowser Quantum

FileBrowser combines three separate ideas. Together they decide whether someone can see a source, open a path, and perform actions there:

  1. User permissions — Global capabilities that apply across sources: admin, api, share, and realtime. File operations (view, download, modify, create, delete) are not global; see per-source permissions below.
  2. Per-source permissions — For each source in a user’s scopes, what they may do with files in that source: view, download, modify, create, and delete. These are configured in User Management on each scope row (v2.0.0+).
  3. Source-level access — Whether the user even has a given source (scopes and defaults such as source configuration, including defaultEnabled and denyByDefault). This is broad: it gates the whole source or the user’s subtree under it, not individual paths inside the tree.
  4. Access control rules — Additional, path-specific allow/deny rules for directories under a source, optionally scoped to users or groups. Use these when you need fine control (“this folder, for this user or group”) rather than changing per-source permissions or whole-source defaults.

Access rules refine which paths under a source are reachable once the user already has that source and sufficient per-source permissions for the action.

Keep reading this page for how path-based rules are evaluated, how they combine with denyByDefault, and worked examples. For the full rule-type reference and precedence details, see Access rules.

Source default behavior

A user’s access to files depends on:

  1. User scope — Users do not see or use a source until it is part of their scopes. New users can get sources automatically when defaultEnabled is true for that source, or an admin can assign sources in user management.
  2. denyByDefault — With a source scope, paths are normally reachable unless the source sets denyByDefault: true. Then the user can still see that the source exists, but file access requires explicit allow rules for the paths they need.
  3. Access rules — Per-path allow/deny (and deny-all) rules for users or groups, as described below.

How access rules work

Directory-level control uses allow and deny rules attached to paths under a source. When someone accesses a file or directory, evaluation proceeds in this order:

  1. Direct path — Rules that match the exact path are considered first.
  2. Parent paths — If nothing applies directly, parent directories are walked toward the root until a matching rule appears or the tree ends.
  3. Default — If no rule applies along that chain, access follows the source default (allow unless denyByDefault is enabled).

Rule precedence and overriding

More specific paths override broader ones: a rule on /folder/subfolder wins over a rule on /folder.

Allow overrides deny when both would apply.

Examples

Example 1: Basic deny

  • Rule: Deny user graham access to /.
  • Result: graham cannot access any files or directories under that scope.

Example 2: Overriding a deny with an allow

  • Rule 1: Deny user graham access to /.
  • Rule 2: Allow user graham access to /subpath.
  • Result: graham can only use /subpath and its subdirectories.

Example 3: Deny-all as a blacklist

  • Rule: Deny-all on /vip.
  • Result: No one can access /vip until an explicit allow rule overrides it for a given user or group.

Configuration

Access rules are configured in the admin UI or via the API: per user or group, per directory, allow/deny/deny-all, with more specific paths overriding broader ones.

Next steps