How access works
The two kinds of role in quickS3, how organisation roles and custom roles differ, and the checks every file action has to pass before it runs.
quickS3 has two kinds of role, and they answer different questions.
Organisation roles (Owner, Admin, Member) decide who runs quickS3: who can invite people, edit roles, manage connections, and read the audit log. Everyone has exactly one. See Owner, Admin, and Member.
Custom roles decide who can open which files. You create them, give them names like “Finance reports”, and fill them with rules like “Allow Read and Write in reports/ in the finance bucket”. Someone can have several. See create a custom role.
The two don’t mix. Making someone an Admin doesn’t give them any files, and giving someone a custom role doesn’t let them manage anything.
What happens when someone opens a file
Every file action, from listing a folder to deleting a file, passes these checks:
- Are they in the organisation? Removed people are refused straight away.
- Are they an Owner? Owners skip the role check and can reach everything.
- Do their custom roles allow it? At least one Allow rule has to match, and no Deny rule can. How rules work explains the matching.
- Does the connection allow it? Buckets outside the connection’s Bucket scopes are off limits.
- Does the storage key allow it? If the key behind the connection can’t delete, nobody can delete through quickS3.
The answer is no unless every check says yes. Someone who’s just joined can sign in, but sees no buckets until a custom role gives them some.
Each yes or no is recorded in the audit log, so you can see who tried what.
Where to go next
- Setting up access for the first time: Admin quickstart.
- Common setups, like a shared upload folder: folder access recipes.
- Someone can’t do something they should: why can’t I do this?