> ## 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`. The remote itself sets `list_version = 2` | | **Notable limits** | Objects up to 5 TB. Multipart parts from 5 MB to 5 GB (max 10,000). `DeleteObjects` batches of 1,000 or less | | **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. ### DataRaven sets Fil One remotes to ListObjectsV2 Fil One has no dedicated rclone backend, so DataRaven configures it as `provider = Other`. rclone picks the S3 listing API from that provider string. `Other` resolves to **ListObjects (V1)**. The Fil One S3 compatibility page lists that API as a known risk in `eu-west-1`. The risk comes from the way V1 continues a listing. V1 continues with a `marker=` parameter. The value of that parameter is a plain object key. In `eu-west-1`, that key carries a server-internal suffix. The shape of the suffix changes at each page boundary: ``` page 1 -> 2 file-1000.txt[minio_cache:v2,return:] page 2 -> 3 file-2000.txt[minio_cache:v2,id:d8582cd1-...,p:0,s:0] ``` Fil One recommends ListObjectsV2 with `ContinuationToken` instead. That token is an opaque base64 string. Nothing between rclone and the service reads it as a key, so the suffix cannot stop the listing. We did not reproduce a failure. Under V1, a listing of 2,001 objects across three pages completed correctly. This risk is latent, not an observed failure. DataRaven sets V2 because Fil One documents the risk, and because V2 returns the same keys. DataRaven therefore writes `list_version = 2` into every Fil One remote. We verified both regions with 2,001 objects: * Each request carries `list-type=2`. * Each new page uses `continuation-token`. * V2 returns the same key set as V1. `us-east-1` returns bare keys as tokens, so that region does not have this risk. DataRaven sets V2 in both regions, so the two regions keep the same config. DataRaven writes this value into the **remote**, not into the task config. The `--s3-list-version` flag in rclone is backend-global. rclone applies one value to every S3 remote in the transfer. This rule includes the remote on the other side of the transfer. Some S3-compatible endpoints return all pages on V1, but fail on V2. A value set on the task therefore applies V2 to the remote on the other side of the transfer. That remote can fail on V2. The config file keeps V2 on the Fil One remote alone. This design has two consequences: * **V2 applies to every Fil One task, including tasks created before this change.** DataRaven builds the remote again on each run, so there is no older task to correct. * **V2 does not appear in the task config.** The detail page of the task shows no `s3_list_version` value. That field stays empty until you set it. To return to auto-detection in rclone, set `s3_list_version: 0` on the task. A value set on the task has priority, because the command-line flag has priority over the config file. ### 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 config 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. * **V1 `ListObjects` markers carry internal state that changes** — see the listing section above. DataRaven sets `list_version = 2` on the Fil One remote. ### 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). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.