Access control in FileBrowser Quantum link

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.

Storage quotas (v2.1.0+) are a separate control: they limit how much data can be stored in a folder, user scope, or share link without changing who can see a path. See Storage quotas (v2.1.0+).

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 link

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. Sources with defaultEnabled: true are granted on user create and, from v2.0.1+, merged for existing users on every server startup. An admin can still assign non-default 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 link

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 link

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 link

Example 1: Basic deny link

• 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 link

• 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 link

• 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 link

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 link

• Storage quotas (v2.1.0+)
• Access rules
• Troubleshooting
• User management