Skip to main content
The catch-all type for any S3-compatible provider without a first-class integration — MinIO, Storj, IDrive e2, Ceph, and anything else that speaks the S3 API.
If your provider has its own page in this section, prefer that type over S3 Compatible — it gets provider-specific endpoint handling, validation, and task defaults.

​
At a Glance

​
Credentials

Create a secret with the S3 Compatible provider type. The auth method is s3_compatible_access_key, which requires: The key needs permission to list, read, write, and delete objects in the bucket — the same operations connection verification tests.

​
Location Setup

Example:

​
Provider Quirks

Many managed S3 providers don’t expose CreateBucket permission, which surfaces as 403 Access Denied during transfers. S3 Compatible locations default to s3_no_check_bucket: true to bypass that check.

​
HTTP/2 stays on

DataRaven leaves HTTP/2 enabled for S3 Compatible locations. The one exception is Filebase, which DataRaven puts on HTTP/1.1. Filebase recycles HTTP/2 connections with a graceful GOAWAY that lands on every upload in flight. Go cannot replay an upload after it writes the request body. That failure looks like this in the execution logs:
If your endpoint produces this error, set disable_http2 in the task’s rclone configuration. This option is task-wide: it puts both remotes of the task on HTTP/1.1. Use it on the tasks that touch the affected endpoint, not as a habit.

​
Importing from rclone.conf

A type = s3 remote whose provider = value isn’t recognized — including provider = Other — imports as S3 Compatible, with its endpoint and credentials carried over. The exception: provider = Other remotes whose endpoint hostname identifies Fil One, Filebase, Tigris, or MEGA S4 are upgraded to those first-class types instead. See the rclone import guide.