Storage

Tenant admin

Storage has three levels, and confusing them is the usual cause of a user saying they cannot mount anything.

Level	What it is	Who sees it
Storage	A physical location: a path on a node, or a shared backend	Admins only
Shared storage	A subdivision inside a storage	Admins only
Bucket	What appears in the file browser and the mount picker	Users

Users only ever interact with buckets. The other two are how you decide where a bucket physically lives.

Storages

Register a storage against the node that holds it. A storage on a node is only reachable from queues that contain that node - which is why the queue’s storage links matter as much as the storage itself.

Shared storages

A subdivision within a storage, used to separate one team’s area from another’s on the same underlying disk.

Buckets

What users see. A bucket is defined inside a storage and granted to a user group or a project, with either read-write or read-only access.

Read-only is worth using for shared datasets: a job that mounts it cannot destroy it.

NetApp

Where the tenant has NetApp integration configured, storage can be backed by NetApp volumes rather than plain node paths.

The two-sided rule

For a user to mount a bucket, both of these must hold:

1. Their group (or a project they are in) grants them the bucket.
2. The queue they selected is linked to the storage that bucket lives on.

Only the first is visible from the user's side

Grant the bucket but forget the queue link, and the user sees the bucket on the Files page and cannot mount it in a job. From their point of view the product is broken. From the Storage page everything looks correct.

Check Queues whenever a mount is missing.

Cost

Storage is billed per terabyte-hour, continuously, independent of any job. A bucket someone filled and abandoned keeps drawing tokens - worth auditing occasionally.