---
title: How allow and deny rules work
description: "What an allow or deny rule is made of, how rules from several roles combine, and why a deny always wins no matter which role it came from."
section: Access
order: 30
audience: [owner, admin]
status: published
lastVerified: 2026-09-15
sources:
  - src/lib/permissions.ts
  - web/src/components/app/permissions/RuleTable.tsx
  - web/src/components/app/permissions/RoleDetail.tsx
---

A role is a list of rules. Each rule is one row in the role editor:

| Column | What it does |
| --- | --- |
| **Effect** | **Allow** grants access. **Deny** takes it away. |
| **Connection** | Which storage connection the rule is about. |
| **Bucket** | Which bucket on that connection. |
| **Prefix** | Which folder in the bucket, like `reports/`. Leave it empty for the whole bucket. |
| **Read**, **Write** | What the rule allows or denies. Tick one or both. |

**Read** covers browsing, previewing, downloading, and creating share links. **Write** covers uploading, overwriting, deleting, and creating folders. [Read and Write](/docs/access/actions/) has the full list.

## How quickS3 decides

For every action someone takes, quickS3 looks at all the rules in all of their roles:

1. If any **Deny** rule matches, the answer is no.
2. Otherwise, if any **Allow** rule matches, the answer is yes.
3. If nothing matches, the answer is no.

That's the whole logic. The order of rules and roles doesn't matter, and a more specific rule doesn't beat a broader one. Nobody has access to anything until a rule allows it.

Owners skip this check. They can reach everything on every connection, which is why you should test new roles with someone who isn't an Owner.

## Why deny always wins

Once you add a Deny rule, you can trust it: no Allow in any other role will reopen that folder by accident. The price is that you can't carve an exception back out of a Deny. To let someone into part of a denied folder, narrow the Deny instead.

The role editor helps you spot conflicts. A rule marked "A deny rule cancels at least one action granted here" is being overridden by a Deny in the same role.

## How prefixes match

A prefix covers that folder and everything inside it.

- `reports/` matches `reports/q1.pdf` and `reports/2026/q1.pdf`.
- `reports/` does not match `reports-old/q1.pdf`. Prefixes always stop at a `/`.
- Slashes at the start or end don't matter: `reports`, `/reports`, and `reports/` are the same rule.
- Prefixes are case-sensitive: `Reports/` and `reports/` are different folders.

Bucket names aren't case-sensitive, but a rule only ever applies to its own connection. A rule for the `assets` bucket on one connection says nothing about an `assets` bucket on another.

## An example

A role with these two rules:

| Effect | Bucket | Prefix | Read | Write |
| --- | --- | --- | --- | --- |
| Allow | `projects` | `incoming/` | ✓ | ✓ |
| Deny | `projects` | `incoming/private/` | ✓ | ✓ |

The person can work anywhere in `incoming/`, including making new folders there. `incoming/private/` doesn't appear in their file list at all, and opening it directly is refused.

For more patterns like this, see [folder access recipes](/docs/access/prefix-recipes/).