User Permissions

FileBrowser Quantum v2.0.0 splits permissions into two layers: global capabilities that apply everywhere, and per-source file permissions that apply to each source in a user’s scopes. The new view grant controls whether someone can browse and preview content in the UI without downloading.

Two permission layers link

Global permissions link

These apply to the user account everywhere. Configure them in Settings → User Management when creating or editing a user.

Per-source file permissions (v2.0.0+) link

These permissions apply to each source.

View vs download link

View and download are separate permissions in v2.0.0+. A user can browse and preview without being allowed to save file bytes — useful for read-only galleries, internal document review, or limiting share recipients to in-browser viewing. This also extends to office integrations.

Inline viewing uses GET /api/resources/view and GET /api/media/stream with a viewToken minted from file metadata. Those endpoints never increment share download counters and never create activity rows. See Activity Viewer and Previewing files.

Which Settings page controls what link

Permission-related options appear in more than one place. Use this table to find the right page:

User defaults (profile theme, preview toggles, global admin/api/share/realtime) are a third, separate template — see User defaults.

Where to configure permissions link

Per-user scopes link

1. Open Settings → User Management
2. Create or edit a user
3. Assign sources and scope paths
4. Expand each source row and set view, download, modify, create, and delete

Default permissions for new scopes link

Settings → Access management defines default permissions used when:

• A new scope is added to a user in the user editor (pre-filled from these defaults)
• A user is auto-created on first OIDC, LDAP, JWT, or proxy login
• Permissions are omitted on API user create for a scope

Built-in defaults when nothing is configured: view and download are true; modify, create, and delete are false.

Changing these defaults does not update permissions on scopes that users already have. After changing defaults, either edit affected users in User management or enable Enforce (below).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

server:
  sources:
    - path: "/data"
      config:
        defaultPermissions:
          view: true
          download: true
          modify: false
          create: false
          delete: false

See User management for the full config reference.

Enforced source permissions link

Admins can enforce individual per-source permission flags in Settings → Access management (enforce toggle next to each default). When enforcement is enabled for a flag:

• The enforced value is taken from the current default for that flag
• All non-admin users are resynced immediately — existing scope values are overwritten to match
• Non-admins cannot override enforced flags in User management
• Admin users are exempt from enforcement

When enforcement is disabled for a flag, changing the default alone does not resync existing users — only toggling enforce on (or editing users individually) pushes values out.

Use enforcement when you need a deployment-wide policy (for example, enable create for everyone, or disable delete on every scope).

How this relates to access rules link

Per-source permissions gate what actions a user may perform on files in a source. Access control rules (allow/deny on specific paths) further refine which paths under that source are reachable. Both must pass for an action to succeed.

An allow rule on a path does not substitute for create, modify, or delete permission on the user’s scope. If create is disabled on the user’s scope row, New file / New folder stays hidden even when an allow rule exists on that folder.

See Access control overview for path-based rules and WebDAV for how each capability maps to client operations.

Troubleshooting: missing New file / New folder link

Common causes when a user can browse but cannot create:

1. Create is off on the user’s scope — Open User management → edit the user → expand the source → enable Create. Access management defaults alone do not update existing users.
2. Defaults were changed after the user was created — OIDC and other auto-provisioned users receive permissions at first login. Change the user record, or Enforce create in Access management to resync all non-admins.
3. Allow rule mistaken for create permission — Path allow rules control visibility; create is a separate scope permission.
4. View without create — View allows browsing and preview; Create is required for new files and folders in the Web UI.

After fixing permissions, the user may need to refresh the browser session so the sidebar picks up updated scope data.

After upgrading from v1.x link

Migration copies each user’s former global file permissions onto every existing scope and sets view to true unless you configured otherwise. After upgrading:

1. Open Settings → User Management for each non-admin user
2. Confirm per-source permissions on every scope row
3. Set default permissions and enforcement in Access management if you want deployment-wide caps

Related topics link

• User defaults — profile preferences and global admin/api/share/realtime template
• User management — YAML config, CLI, and API user shapes
• Access control overview — path-based allow/deny rules
• WebDAV — per-source permission matrix for WebDAV clients
• About v2.0.0 — full release summary