Shares and quotas
Shares are the unit of collaboration. Every file lives in exactly one share. Members of a share see the share in their sidebar with the role they've been granted. Quotas cap how much storage a share, user, or tenant can consume.
Creating a share#
Storage → Shares → New share:
| Field | Notes |
|---|---|
| Name | What users see. Renameable later. |
| Slug | URL-safe identifier. Used in API paths. Hard to change once files exist. |
| Type | central (team), personal (user's home), or project (time-bound). |
| Owner | A user. Default is you. |
| Quota | Bytes, or "inherit from tenant." Defaults to tenant default. |
| Visibility | private (members only) or discoverable (listed for any user, can request access). |
Click Create — the share is live. Add members from the share detail page; see Sharing with your team for the user-facing flow.
Share types#
central— long-lived team or department share. The default. Has explicit members.personal— created automatically when a user signs in for the first time; this is their home share. One per user, owned by them, quota from the user's personal quota.project— same as central but flagged as time-bound; appears in a "Projects" filter and can have an auto-archive date. Useful for short-lived shares so they don't clutter the central list forever.
Quotas#
Quotas exist at three levels. Each level caps everything below it.
| Level | Caps | Set in |
|---|---|---|
| Tenant | Total storage for the whole tenant | System → Tenants → tenant detail |
| Share | Storage on this share | Storage → Shares → share detail |
| User | Personal share usage (not shares others own) | People → Users → user detail |
A 100 GB upload fails if it would push any of user usage + share usage + tenant usage over its cap. The error message tells the user which level was hit.
Soft vs hard quotas#
By default, exceeding a quota blocks further uploads — a hard cap. You can change a quota to soft (warn but don't block) per-share or per-user. Soft is sensible for ongoing user education; hard is sensible for cost control.
A quota in soft mode still sends warning notifications; it just doesn't 507 the API.
Usage tracking#
Storage → Quotas shows current usage per share and per user, with sparklines for the last 30 days. Click a row for a per-file breakdown.
Usage is recomputed:
- Immediately on upload, delete, or restore.
- Every hour by a background job (covers the rare drift case).
- On demand: Recalculate button on any row.
If a number looks wrong, Recalculate is the right answer — it walks the file table and resets to ground truth.
Quota history#
Storage → Quotas → History plots tenant and per-share usage over time (daily snapshots). Useful for capacity planning. Snapshots are retained per the Operations → Retention policy.
Permissions and ACLs#
Share-level role is the coarse permission. For finer-grained access:
- Folder ACLs — restrict who sees a subfolder. See Permissions and ACLs.
- File ACLs — explicit per-file allow/deny. NTFS-style; deny wins.
Admins can edit ACLs from the share's Permissions tab in the user-facing web client; they're not separately exposed in the admin console.
Deleting a share#
Storage → Shares → share detail → Danger zone → Delete.
Deleting a share permanently removes:
- All files in the share, including version history.
- All external links pointing at content in the share.
- All membership records.
Two safety guards: (1) shares under a legal hold can't be deleted; (2) you must type the share's slug to confirm.
If you want to keep the data but stop access, use Archive instead — moves the share to read-only and hides it from sidebars; reversible.
What's next#
- Users and groups.
- External link policy.
- Compliance policies — legal holds, retention, DLP.