> ## Documentation Index > Fetch the complete documentation index at: https://docs.dataraven.io/llms.txt > Use this file to discover all available pages before exploring further. # Fil One > Connect Fil One buckets as sources and destinations for transfer tasks. Fil One — S3-compatible object storage built on Filecoin, with always-on encryption at rest and optional versioning and object lock. Access keys are region-scoped, which shapes how you organize secrets, and the two regions differ in API surface **and behavior** in ways worth knowing before a big migration — most importantly, `eu-west-1` cannot pass rclone's checksum verification, so DataRaven sets `ignore_checksum` automatically on transfers that touch that region (see [below](#eu-west-1-checksum-verification-fails-without-ignore-checksum)). ## At a Glance | | | | ------------------ | ----------------------------------------------------------------------------------------------------------------- | | **Region** | Required — `eu-west-1` (EU, France) or `us-east-1` (US East, Michigan) | | **Endpoint URL** | Derived from region — `https://.s3.fil.one` | | **Credentials** | Access key — `access_key_id`, `secret_access_key` | | **Task defaults** | `s3_no_check_bucket: true`, `fast_list: true`; on `eu-west-1` also `ignore_checksum: true` | | **Notable limits** | Objects up to 5 TB; multipart parts 5 MB–5 GB (max 10,000); `DeleteObjects` batches of ≤ 1,000 | | **Provider docs** | [docs.fil.one](https://docs.fil.one) · [S3 compatibility matrix](https://docs.fil.one/reference/s3-compatibility) | `s3_no_check_bucket` is on by default because `CreateBucket` only exists in `us-east-1` — in `eu-west-1` buckets are created through the Fil One dashboard — and is an explicit key permission even where it exists. Skipping rclone's bucket-existence check avoids a spurious failure against a bucket that is already there. ## Credentials Create a [secret](/secrets) with the **Fil One** provider type. The auth method is `filone_access_key`, which requires: | Field | Description | | ------------------- | ------------------------- | | `access_key_id` | Fil One access key ID | | `secret_access_key` | Fil One secret access key | Fil One access keys are **region-scoped**: a key created for one region only authenticates against that region's endpoint. If you store data in more than one Fil One region, create a separate secret per region. Keys are created in the Fil One dashboard and can be scoped to specific buckets and permissions — worth doing for a transfer key that only needs one bucket. Note that `CreateBucket` and `DeleteBucket` are explicit permissions a key must be granted; a default key cannot create buckets even in `us-east-1`. ## Location Setup | Field | Value | | ----------------- | --------------------------------------------------------------- | | **region** | Required — `eu-west-1` (EU, France) or `us-east-1` (US East) | | **endpoint\_url** | Optional — derived from region as `https://.s3.fil.one` | A bucket's region is fixed when the bucket is created and data cannot be moved between regions afterwards, so the location's region simply matches where the bucket lives. Fil One requires **path-style addressing** and HTTPS — the configuration DataRaven generates uses both, so there is nothing to set up. Example: | Field | Example value | | -------------- | -------------- | | name | `Fil One EU` | | location\_type | Fil One | | bucket\_name | `acme-archive` | | region | `eu-west-1` | ## Provider Quirks ### Bucket naming — no dots Fil One does **not** allow dots (`.`) in bucket names, which S3 permits. An S3 bucket named like a hostname — `backups.example.com` — needs a new name on the way in. The full rules: * 3–63 characters * Lowercase letters, numbers, and hyphens only — no dots * Must begin and end with a letter or number * Unique within Fil One DataRaven checks these rules when you create the location, so a non-conforming name fails immediately with a clear message instead of surfacing later as an error from the service. Object **key** handling depends on the region. In DataRaven's end-to-end transfer tests, `us-east-1` accepted everything S3 does — keys with consecutive slashes (`//`), trailing slashes on objects with content, Unicode, and 250+ character paths all copied in unchanged. `eu-west-1` **rejects keys containing consecutive slashes** with a 400 (`Object name contains unsupported characters`), so a transfer carrying such keys fails on those objects mid-run — check source keys before a migration into `eu-west-1`. ### eu-west-1: checksum verification fails without `ignore_checksum` In `eu-west-1`, the ETag returned for an uploaded object is **not the object's MD5** — the storage layer encrypts at rest and returns a value that changes on every upload, even for identical content. rclone's default post-copy verification compares the source MD5 against that ETag, so **every uploaded object is reported "corrupted on transfer" and the failed copy is then removed from the destination**: a default-configured transfer into `eu-west-1` fails and leaves almost nothing behind. DataRaven handles this automatically: every execution whose source or destination is a Fil One `eu-west-1` location runs with `ignore_checksum: true`. The flag is resolved at execution time — like plan limits — from the endpoint the transfer actually uses (an explicit endpoint URL wins over the region field), so it follows a region change immediately; to opt out, set `ignore_checksum: false` explicitly in the task's rclone configuration. Objects are still verified by size, and uploads still carry a `Content-MD5` that the service checks on receipt — only the after-the-fact ETag comparison, which has no valid MD5 to compare against, is skipped. `us-east-1` returns standard MD5 ETags and verifies checksums cleanly — no flag needed there. Large objects uploaded via multipart are unaffected in both regions, because multipart ETags are never plain MD5s and rclone skips that comparison automatically. ### The two regions differ in API surface `us-east-1` supports the larger slice of the S3 API. In `eu-west-1`: * **Buckets are created and deleted in the dashboard only** — `CreateBucket` and `DeleteBucket` are not available via the API (this is why `s3_no_check_bucket` is a task default). * **ETags are not content MD5s** — see the checksum warning above; DataRaven defaults `ignore_checksum` on for transfers touching this region. * **Keys with consecutive slashes (`//`) are rejected** at upload with `Object name contains unsupported characters`; `us-east-1` accepts them. * **`CopyObject` is not confirmed.** Cloud-to-cloud transfers into Fil One never need it, but rclone uses it to rewrite an object's metadata in place — updating only a modification time on an otherwise unchanged object. If a sync keeps erroring on objects whose content hasn't changed, this is the likely cause; setting `size_only` in the task's rclone configuration compares by size alone and sidesteps the metadata rewrite. * **Missing resources can return `AccessDenied` (403) instead of 404.** When troubleshooting, a permission error against `eu-west-1` may actually mean a mistyped bucket or path. ### Versioning and object lock are set at bucket creation — permanently Versioning is opt-in when the bucket is created and can never be suspended afterwards. Object lock (Governance or Compliance mode, with a default retention of 1 day to 100 years) requires versioning and is likewise fixed at creation. Two implications for transfer tasks: * **On a versioned destination, every overwrite is a new full copy.** A sync task that repeatedly rewrites changed objects grows the version stack, and every version is billed as stored data. Deletes place a delete marker; prior versions remain and remain billed. * **Locked versions cannot be overwritten or deleted.** On a bucket with object lock, sync operations that would replace or prune an object inside its retention window fail with `AccessDenied` — expected behavior, not a credentials problem. ## Performance Notes Fil One publishes no numeric rate limits. `SlowDown` (503) responses are throttling, not failure — rclone backs off and retries automatically; if they persist in execution logs, lower `transfers` in the task's rclone configuration. For large objects, throughput scales with multipart settings: raise `s3_chunk_size` (e.g., `64M`) and `s3_upload_concurrency` in the task's rclone configuration rather than file-level `transfers`. Parts can be 5 MB–5 GB with up to 10,000 parts per object, so any object up to the 5 TB maximum is reachable with room to spare. Fil One does **not** expire incomplete multipart uploads. If a large-object transfer is interrupted partway, the already-uploaded parts remain in the bucket — invisible in listings but billed as storage — until explicitly aborted. Fil One's [multipart upload guide](https://docs.fil.one/storage/multipart-uploads) shows how to list and abort stale uploads with the AWS CLI. ## What Transfers — and What Doesn't Fil One stores object data and standard metadata, and supports more of the S3 feature set than most S3-compatible providers — but not all of it (see the [compatibility matrix](https://docs.fil.one/reference/s3-compatibility)). Migrating from S3: | S3 feature | On Fil One | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Object data & metadata | Transfers | | Versioning | Supported — but the current version of each object transfers; version history does not carry over. Enable versioning on the destination bucket at creation to keep history going forward | | Object lock / legal hold | Supported — but per-object retention does not carry over. A destination bucket created with object lock applies its default retention to arriving objects | | Object tags | Not supported today (planned) — tags do not carry over | | ACLs / bucket policies | No ACL or policy model — canned ACL headers are silently ignored; all access is via authenticated keys | | Server-side encryption config | Encryption at rest is always on, with keys held by Fil One; SSE-KMS and SSE-C are rejected | | Storage classes / lifecycle | Single storage class; lifecycle rules are not supported today (planned) | ## Importing from rclone.conf Fil One has no `provider =` value of its own in rclone, so real configs write `provider = Other`. The importer recognizes Fil One remotes by their endpoint hostname (`*.s3.fil.one`) instead of falling back to S3 Compatible, and a config that carries only the endpoint is fine — the region is recovered from the hostname. Because access keys are region-scoped, each imported remote maps cleanly to one region's secret. See the [rclone import guide](/guides/import-rclone-config).