How allow and deny rules work

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 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.