If you download rclone.conf from the panel (Buckets → Download rclone.conf), uploads work immediately. If you hand-write a config with just your endpoint and keys, they fail — sometimes the file even seems to upload and then disappears. This is expected, and it comes down to three settings the generated config carries. Here is what each does and why it is required.
The minimal working config
[buckets-ninja]
type = s3
provider = Minio
env_auth = false
access_key_id = YOUR_ACCESS_KEY
secret_access_key = YOUR_SECRET
endpoint = https://s3.buckets.ninja
acl = private
no_check_bucket = true
upload_cutoff = 0
use_multipart_etag = false
The first block is what any S3 remote needs. The three lines at the bottom are the ones people leave out — and each corresponds to a real behaviour of the service.
1. no_check_bucket = true
By default, before its first upload rclone checks that the bucket exists and tries to create it if it thinks it does not. On buckets.ninja, buckets are created in the panel, and your access keys are not permitted to create buckets over S3 (this keeps provisioning and billing in one place). Without no_check_bucket, rclone's create attempt is denied and the whole transfer fails before a single object is uploaded.
With it set, rclone skips the check and writes straight into the bucket you already created.
2 & 3. upload_cutoff = 0 and use_multipart_etag = false
This is the subtle one, and the reason a hand-written config can look like it corrupts data.
Your objects are encrypted at rest. That means the ETag the server returns after an upload is not the MD5 of your file — it cannot be, because what is stored is ciphertext. Left to its defaults, rclone compares the ETag against the MD5 it calculated locally, sees they differ, concludes the transfer was corrupted, and deletes the object it just uploaded. The upload appears to succeed and then the file is gone.
The two settings fix this without giving up integrity checking:
upload_cutoff = 0sends every file as a multipart upload. For multipart objects rclone records the real MD5 in the object's metadata and verifies against that, instead of against the ETag.use_multipart_etag = falsestops rclone trying to reconstruct a multipart ETag it has no way to predict for an encrypted object.
Together they mean rclone check and rclone sync verify your data correctly, end to end. The only cost is a few extra requests per object — and those are Class A (write) calls, which are always free here, so it costs you nothing.
Do not add
--ignore-checksum. It is the usual advice for "checksum mismatch" errors, but here it would switch integrity checking off — the exact thing these two settings preserve. You want verification on; you just want it done against the stored MD5 rather than the ETag.
The other lines
provider = Minio— the storage is MinIO-based; this tells rclone which S3 dialect to speak.env_auth = false— use the keys in the file, not credentials from the environment.acl = private— objects are private to your account. Public buckets are not a feature of this service.
Adding client-side encryption
Your data is encrypted at rest, but with keys we hold. If you want us to be unable to read it at all, layer an rclone crypt remote on top of this one — see the encryption guide for the full walkthrough. The downloaded rclone.conf includes a ready-to-uncomment [buckets-ninja-crypt] block for exactly this.
Still failing?
- AccessDenied on upload — confirm the bucket name matches one you created in the panel, and that your key has not been suspended for an unpaid balance.
- SignatureDoesNotMatch — the access key and secret have drifted apart; generate a fresh key pair in Buckets → Access keys and update the config.
- Cannot list buckets — that call is intentionally disabled; address your bucket by name rather than letting the client discover it.