Skip to main content

​
Volume statuses

Snapshots use a shorter set: creating, available, deleting, error.

​
Quotas

Four storage counters, all scoped to your organization within a region:
Quota is consumed for the lifetime of a row, not just while it is healthy. A volume parked in error still counts against volumes and volume_storage_gb — which mirrors what you can see — so delete failed volumes rather than leaving them.
An extend reserves the delta before it starts, so an extend that would cross volume_storage_gb is refused up front rather than half-applied.

​
Listing and pagination

Volumes, snapshots and policies are listed newest-first and paginated with an opaque cursor. Pass marker from the previous page’s meta to get the next one:
Do not infer the end of a list from a short page. Read meta.has_more, and keep passing meta.marker until it is false — a page can come back smaller than the limit you asked for.
Volume and snapshot listings also take name (case-insensitive substring) and status; snapshots take volume_id to narrow to one volume, and policies take volume_id and enabled.

​
Troubleshooting

Not every tier a volume can report is one you may create on. Use ssd or nvme. GET /v1/volume-types always lists exactly what is creatable.
The volume is not in available. Attached volumes (in_use) are the common case — detach, extend, re-attach. A volume mid-creating, extending or deleting also refuses, and settles on its own.A boot volume can never reach available while its instance exists, so an extend on one has no path to success. Move the data onto a separate volume, or rebuild the instance with a larger boot volume.
List them with GET /v1/snapshots?volume_id=<id> and delete them first. If a snapshot policy is still attached it may be creating new ones behind you — delete the policy, or pause it with enabled: false, before clearing the backlog.
Read last_error on the policy. The usual causes are an exhausted snapshots quota — clear space by lowering retention_count or deleting old snapshots — and a volume that was in a transient state when the window came around, which resolves itself on the next run.A policy with enabled: false produces nothing at all, and next_run_at tells you whether the schedule believes it is due.
A restore clones the snapshot and then grows to the size_gb you asked for, so it is never smaller than the snapshot’s frozen size. The filesystem inside it is still the size it was when the snapshot was taken — expand it in the guest.
error_message carries the last failure. The row keeps its quota while it exists, so delete a volume or snapshot you do not intend to retry.

​
Quotas

Two counters, both scoped to your organization within a region: object_storage_gb is enforced by comparing what you actually store against the limit, not by a running counter. That means space freed by a lifecycle expiration, a version delete or a bucket purge comes back on its own — there is no counter left holding a phantom charge against your cap.

​
Troubleshooting

The secret does not match the access key, or something the client signed was rewritten in transit. Check first that the credential is right, then that your client is signing with SigV4 (signature_version="s3v4") — the endpoint accepts nothing older.A key or query value containing a space or a + is a classic case: those have to be percent-encoded in the canonical request, and an SDK doing it correctly will interoperate.
Your clock is more than 15 minutes from the server’s. Fix time sync on the machine making the request; there is no way to widen the window.
An explicit deny in either layer wins, so start there: a bucket policy denying something is enough to block a caller their IAM policies allow, and the reverse holds too. With no explicit deny anywhere, you need an allow from one of the two — a bucket policy that names other principals is not itself a denial, but it will not stand in for the IAM grant you are missing.Deleting an object also fails with 403 when it is protected by an active retention period or a legal hold, which reads like a permission problem but is not one.
Objects, versions, or in-flight multipart uploads remain. List uploads with GET /v1/buckets/{bucket}/multipart-uploads — an abandoned upload holds the bucket open just as an object does, and does not show in an object listing.
A part other than the last one is under 5 MiB. The floor is checked when the upload completes, so this surfaces after every part has been staged. Re-upload with larger parts.
A bucket default applies to writes made after it was set; existing objects are untouched. Re-upload anything already stored if you need it covered. Check ServerSideEncryption on a HEAD of the stored object, which is the only answer that reflects what was written.

​
S3 error codes

The S3 endpoint answers in S3’s own XML vocabulary, so an SDK’s error handling works unchanged: