Problem: MinIO community edition is archived / unmaintained — what to do with a Docker-deployed file service (migrate to RustFS, zero data loss) —— Trove problem library

What you will run into

MinIO community edition entered maintenance mode in Dec 2025, and the GitHub repository was archived read-only in Feb 2026: no more commits, disclosed CVEs no longer fixed, official resources moved to the commercial AIStor subscription.

Running community edition for a file service (e.g.

a Docker-deployed object store) means sitting on an unpatched black box. Another typical trigger: after upgrading your client, uploads fail with XAmzContentSHA256Mismatch — not a config mistake.

New AWS SDK v2 defaults to streaming chunked signatures; old MinIO cannot parse them, and it will never be fixed.

Why this happens

• The freeze is a fact: MinIO froze the community edition; security fixes are "evaluated case by case"; the repo README says "THIS REPOSITORY IS NO LONGER MAINTAINED".
• The signature break is collateral damage: AWS SDK v2 defaults to streaming chunked signatures; old MinIO only supports classic signatures, so uploads report XAmzContentSHA256Mismatch with no upstream fix ever.
• Why zero-data-loss migration works: on disk, MinIO does not store "one object = one file" — each object is a same-named directory (xl.meta metadata + shards). RustFS (since 1.0.0-alpha.89) reads that disk format directly — an entire-directory cp -a is enough, data never crosses the network, and keeping the old directory is a natural rollback backup.

The truth of "no longer maintained" is in the ecosystem contract, not the code itself: after MinIO froze its community edition, the upstream (AWS SDK v2) kept evolving;

the new SDK defaults to streaming chunked signing while old MinIO only supports the classic signature — MinIO is not "broken", it just stopped following upstream contract changes, so the signature handshake necessarily fails and the official project will never fix it.

Zero-loss migration rests on the disk format: MinIO is not "one object one file" but an object-named directory (xl.meta metadata + shards);

RustFS directly understands that disk format, so cp -a of the whole directory preserves metadata and shards as-is, and data never crosses the network.

Deterministic takeaway: for S3-compatible services, migrate based on "disk-format compatibility" rather than "API compatibility" (API compatibility can break anytime; disk-format compatibility enables offline migration);

keeping the old directory untouched is a natural rollback backup — verify reads/writes after migration, and if verification fails, switch back;

fixed diagnostic: XAmzContentSHA256Mismatch = signature generation mismatch, not network or config.

Step by step

1. Stop old MinIO, but record the data dir first — Required

From docker inspect, note the Mounts Source (host path) and Destination (container path; usually /data for MinIO). Removing the container is fine — data lives in the host directory.

2. Copy the whole directory (do not cherry-pick files) — Required

ls /data/public shows not image files but same-named object directories (xl.meta + shards), so "copy the objects" does not work. cp -a the whole data dir to a sibling new dir; the old dir stays intact as a rollback backup.

3. chown 10001 before starting (the step where almost everyone breaks) — Required

The MinIO image runs as root and can write anywhere; the RustFS image declares USER 10001 in its Dockerfile and runs non-root. Bind mounts do not translate permissions — when UID 10001 writes /data, the kernel checks the host directory owner.

Without chown the container starts but cannot write.

Do not use chmod 777 (opens write access to every user on the server).

4. Start RustFS and verify — Required

• docker ps shows Up; docker logs rustfs has no errors.
• Console http://server-ip:9001 — sign in with the AK/SK from startup; you should see the old MinIO buckets and files directly.
• API check (S3-compatible): list_buckets shows the old bucket, the old object reads back, a new object writes.

5. Switch the client side too (easy to forget) — Required

Old MinIO Service Accounts do not migrate: point the app at the new AK/SK from RustFS startup.

Java/Go/Python SDKs only need endpoint + credentials changed; for direct-IP use enable path-style addressing (pathStyleAccessEnabled(true)), otherwise virtual-host addressing puts the bucket name into the hostname and DNS resolution fails.

How to confirm it works

# S3 API check: old bucket visible + old object readable + new object writable (actual output)
buckets after migration: ['legacy-bucket']
legacy object readable: b'hello from minio legacy'
new object roundtrip: b'written on rustfs after migration'

Old buckets/files visible in the web console = end-to-end migration done.

Other environments

Symptom

MinIO community repo archived read-only / README says unmaintained; uploads fail with XAmzContentSHA256Mismatch after SDK upgrade; a Docker-deployed object store needs migration but data loss is feared.

Cause

MinIO moved official resources to commercial AIStor; community CVEs are no longer fixed; AWS SDK v2 defaults to streaming chunked signatures which old MinIO cannot parse (never fixed); RustFS reads the MinIO disk format (≥1.0.0-alpha.89) so a whole-directory copy gives a zero-network migration.

Solution

cp -a the old MinIO data dir → chown -R 10001:10001 → docker run RustFS with the copied dir → update app AK/SK (enable path-style for direct IP) → verify old buckets/objects in console/API plus a new write.