Migrate MinIO IAM to RustFS (2026): Users, Policies, and Access Keys
Move MinIO users, policies, and access keys to RustFS: in-place, or by export/import to a new host. LDAP, OIDC, lifecycle rules, and bucket notifications don't transfer.
MinIO stores IAM separately from object data, so migrating buckets does not migrate users, groups, policies, or access keys. Whether IAM reaches RustFS depends on the migration path:
- Binary swap (in-place): RustFS reads MinIO's existing config directory. Built-in IAM carries over with no extra step.
- New host (
mc mirroror Godwit Sync): only object data moves. IAM needs a bulk export and import. - Any path: LDAP and OIDC identities do not transfer.
This guide covers the IAM steps for each path. For the data migration itself, see Migrate MinIO to RustFS.
Hands-on lab available: Export built-in IAM from MinIO and import it into a fresh RustFS instance in Docker, then verify a migrated access key authenticates and its policy is enforced. Go to the lab
mc admin Commands Fail Against RustFS
The MinIO Client (mc) handles both object operations and admin operations, but those two surfaces behave differently against RustFS. Object commands (mc cp, mc ls, mc mirror) work fine because they use the S3 API, which RustFS implements fully. Admin commands are a different story: mc admin user list and mc admin policy list fail, and mc admin policy list returns HTTP 500. The routes exist in RustFS under /minio/admin/v3/, but the handlers are incomplete or return a response shape mc does not parse. The bulk export and import path below works around all of this.
Path A: Binary Swap Carries Built-In IAM In-Place
The in-place binary replacement points RustFS at MinIO's existing data and config directory. RustFS reads the stored IAM config, so built-in users, groups, policies, service accounts, and access keys are present after startup without a separate IAM migration step.
After RustFS starts:
- List users and policies in the RustFS console and confirm the expected set is present.
- Authenticate a client with an existing access key against an allowed bucket.
- Rotate the root credential. The former MinIO root key is now a RustFS admin key.
Path B: New Host Requires Export and Import
When data moved to a fresh RustFS host through mc mirror or Godwit Sync, only objects crossed the network. The source config directory stayed on the old machine. Export IAM from MinIO, then import it into RustFS.
mc admin cluster iam export produces a zip of users, groups, policies, service accounts, and policy mappings. RustFS accepts that zip at PUT /rustfs/admin/v3/import-iam. Send it with curl; mc cannot reach this endpoint.
# Step 1: export IAM metadata from the source MinIO
mc admin cluster iam export source
# produces: source-iam-info.zip (users, groups, policies, service accounts, mappings)
# Step 2: import into RustFS via its admin endpoint (NOT mc)
curl -X PUT \
--user "RUSTFS_ROOT_USER:RUSTFS_ROOT_PASSWORD" \
--data-binary @source-iam-info.zip \
"http://rustfs.internal:9000/rustfs/admin/v3/import-iam"
The RustFS console also accepts the same export zip: upload it from the IAM import screen in the UI instead of calling curl. Both paths hit the same import-iam handler.
The import-iam endpoint is undocumented and pre-stable; the auth scheme may differ on your build. The steps here were verified against RustFS 1.0.0-beta.6. If the import does not succeed, the exported zip contains the full IAM config to recreate manually. To test the export and import end to end against disposable containers first, use the hands-on lab.
What Migrates and What Does Not
| Configuration | Migrates | Method |
|---|---|---|
| Built-in users and groups | Yes | Path A in-place, Path B via export/import |
| Canned and inline policies | Yes | Same |
| Service accounts and access keys | Yes | Same; built-in secrets are included in the export |
| LDAP / OIDC / AD identities | No | Identities live in the provider; rebind the IdP, then mappings apply |
| Bucket lifecycle rules | No | Recreate manually |
| Bucket notifications | No | Recreate manually |
Verify Users and Policies on RustFS
mc admin user list does not work against RustFS. List users and policies through the RustFS console or API, then test enforcement: a migrated key should perform an allowed operation and be denied a disallowed one.
aws s3 ls s3://allowed-bucket --endpoint-url http://rustfs.internal:9000
aws s3 ls s3://forbidden-bucket --endpoint-url http://rustfs.internal:9000 # expect AccessDenied
For data-side verification, see Verifying S3 Migrations.
Bucket Quotas
RustFS enforces per-bucket quotas (Hard type only) at /rustfs/admin/v3/quota/{bucket} with PUT, GET, and DELETE. mc quota does not work against RustFS. If the source used bucket quotas, reapply them per bucket against the RustFS admin endpoint after the IAM import.
Frequently Asked Questions
Do I have to recreate MinIO IAM by hand in RustFS?
No. The binary swap carries built-in IAM in place; a new-host move imports it through import-iam. Manual recreation is a fallback.
Why do mc admin user and mc admin policy fail on RustFS?
RustFS uses the /rustfs/admin/v3/ admin namespace; mc targets MinIO's /minio/admin/v3/. Object commands still work over the S3 API.
Can I migrate LDAP or OIDC users? No. Those identities live in the external provider. Only policy mappings move. Reconnect RustFS to the same provider.
Does the binary swap keep my users and access keys? Yes. RustFS reads MinIO's existing config directory. Verify the set and rotate the root credential.
Is import-iam safe to use?
Yes. As standard practice, import into a fresh instance, inspect the zip first, and rotate credentials afterward.
Do migrated service-account secret keys still work? Yes. The MinIO export includes built-in service-account secrets, so imported service accounts keep their keys.
RustFS is an independent open-source project. "MinIO" is a registered trademark of MinIO, Inc. References to MinIO are for compatibility and comparison purposes only.