When something is wrong

Check and connect and Test connection run a short list of checks on your bucket: the address answers over https, the keys are valid, Plune can write, read and delete in the folder, CORS lets the dashboard read and add files and the bucket is private. When one fails, its cause is shown in words with a How to fix link that lands on the section of this page named for it.

Nothing is saved while a check fails, and the form keeps what you typed. Fix what is marked and check again. The advice here is the same for every provider; the provider pages say where each setting is.

Unreachable

Plune could not reach the address. Plune connects from the internet, over https, to a public address.

Check the Server address for a typo, and that it starts with https://.
For AWS S3 and Cloudflare R2 the address is built for you from the region or the account ID: a typo in those is the likely cause.
The address must be open to the public internet. A private address, localhost, a VPN-only host or a server behind a firewall that does not admit Plune cannot be used. Plune also does not follow redirects.
A service that is down gives the same message; try again later.

TLS

The address answered, but its certificate is not one Plune trusts. The service uses a self-signed certificate, an expired one, or one for another name.

Use a certificate from a public authority (a free one from Let’s Encrypt is fine), and make it cover the name in Server address. A self-signed MinIO needs a proper certificate in front of it.

Bad credentials

The server did not accept the keys.

Check the Access key ID and the Secret access key. Paste them again; a space at an end or a missing character is the commonest cause.
The key may have been deleted, or may have expired. IDrive e2 keys have an expiry date, and Backblaze B2 keys may have a duration.
On Backblaze B2 the master application key does not work with the S3 address; make an application key.
Keys belong to one region on IDrive e2: the key and the server address must be of the same region.
A wrong Region can look like bad credentials on some services; compare with Wrong region.

No bucket

There is no bucket with this name at this address.

Check the Bucket name letter by letter, without s3:// or a path.
The bucket must be in the account whose key you gave, and at the address you gave: another account’s bucket, or a bucket in another region of a service with an address per region (Wasabi, Backblaze B2), is not found.
For Cloudflare R2, check the Account ID, and that the bucket does not have an EU or FedRAMP jurisdiction, which has its own address (R2).

Wrong region

The bucket lives in another region.

On AWS S3, set Region to the bucket’s own: its Properties page in the S3 console shows it (eu-central-1, not Europe (Frankfurt)).
On Other, set Region to what the service expects (the services), and the Server address to the region the bucket was created in.

Write denied

The keys cannot write inside the folder.

Give the key the permission to write (s3:PutObject on AWS) on the folder: arn:aws:s3:::<bucket>/plune/*. The Folder in Plune and the folder in the policy must be the same.
On Backblaze B2 the key needs Read and Write on this bucket; on IDrive e2, Read and write; on Cloudflare R2, Object Read & Write scoped to this bucket. A read-only key stops here.
A bucket policy that denies the key, or an Object Lock or retention rule, can also refuse a write.

Read denied

The keys can write but not read the file back.

Give the key the permission to read (s3:GetObject on AWS) on the same folder.
On a bucket encrypted with your own KMS key, the key also needs kms:Decrypt on that KMS key (AWS S3).
An upload-only key (for example IDrive e2’s Upload only) cannot read; make it Read and write.

Delete denied

The keys cannot delete. The check file is still in the folder: delete it by hand in your bucket’s console, and give the key the permission to delete.

On AWS, s3:DeleteObject on the folder.
On Backblaze B2, deleting a file needs both writeFiles and deleteFiles; make sure the key has them.
On IDrive e2, allow object deletion when you create the key (not bucket deletion).
On Cloudflare R2, whether the Object Read & Write token may delete is not spelled out in R2’s page; if only this step fails, that is the place to look, and tell us.
Object Lock or retention on the bucket blocks deletion until the retention ends.

Without the delete right the connection cannot be used: Plune deletes its own check file, and the object of an upload that was never finished; deleting a result’s files with the result is #948.

CORS missing

No CORS rule on the bucket allows GET from the dashboard’s address, so traces and text files would not open. Screenshots and videos do not need it.

Add the rule on CORS: GET and PUT, from https://app.plune.ai (the beta is https://beta.plune.ai). The place to paste it: AWS S3, Cloudflare R2, other services. Wait a few seconds and press Test connection.

If the rule is there and the check still fails, compare the address in the rule with the one shown in the check letter by letter (https, no slash at the end, no path), and see whether the service takes CORS rules at all (Wasabi applies its own; see Wasabi).

CORS put missing

The bucket lets the dashboard read files, but not put a person’s file: its CORS rule needs PUT and the content-type header. With #1341.

The rule lets the dashboard read — screenshots, text and videos open — but a file a person adds to a case or to the case being marked does not reach the bucket. Add PUT to the rule’s methods and content-type to its headers: the rule, where How to fix on this line goes. Wait a few seconds and press Test connection.

Provider cap

The provider’s daily limit for transactions or download is used up. Raise it in the provider’s console (for Backblaze: Caps & Alerts); it resets daily. The key is fine. The write, read or delete step of the check, or a CLI import, got a refusal from the provider that says a cap or quota was exceeded.

On Backblaze B2 the refusal reads Cannot download file, download bandwidth or transaction (Class B) cap exceeded. Open Caps & Alerts, raise or remove the cap, and note that an account without a payment method has daily caps that are easy to use up. Counters reset at 12:00 AM GMT. Details and what each class counts: Backblaze B2.
Do not change the key: it is not the cause. Press Test connection once the limit is raised.
In a Plune version without this message, the same refusal shows as Read denied, and the CLI prints bucket_unreachable (A file cannot be confirmed).

Unexpected

The bucket answered in a way Plune does not know. The check shows the HTTP status the bucket answered with. It is the cause of last resort: the bucket replied, with a status no other cause names.

A 403 usually means a permission or a policy that denies the key: compare the policy with the one on your provider’s page.
A 301 or a 400 with a message about the region or the endpoint usually means a wrong Region or Server address.
A 5xx is the service having trouble: try again later.
Try path-style on, or off, on the Other provider.

If it persists, send us the status and the provider.

Bucket is public

This is a warning, not a failure: the check passes, but the bucket is public — anyone with its address can read the files. Turn public access off — Block all public access on AWS S3, the bucket’s private setting on other services — and press Test connection. Why: Who can do what.

A file cannot be confirmed (503)

This one does not appear in the settings screen; it is what the CI gets. After a file has been sent, the reporter says “done”, and Plune asks your bucket for that file before it counts. If the answer is not a clear there it is or there is none, Plune replies 503 bucket_unreachable, which means try again.

On AWS S3, the usual cause is a missing s3:ListBucket on the key, or a missing s3:GetObject. Without the listing right, AWS answers 403 for a file that is not there, and Plune cannot tell that from not allowed to read. Add the statements from the policy; with them, a file that never arrived gets the precise 422 file_missing instead.
On Backblaze B2, the cause can be a daily limit (Class B, the reads) rather than the key; see Provider cap.
Retrying will not help until then. A line that is never confirmed is removed by a nightly cleanup once it is more than an hour old.
A bucket that is briefly unreachable gives the same 503, and there a retry is right.