Skip to main content
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).

​
At a Glance

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 with the Fil One provider type. The auth method is filone_access_key, which requires:
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

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:

​
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 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). Migrating from S3:

​
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.