This is a single-page catalog of the issues that recur when operating MinIO community edition. One thing sets it apart from a general troubleshooting list.

The github.com/minio/minio repository was archived in April 2026, and the last substantive code commit was 24 October 2025. That does not merely mean no new features — it means no bug fixes and no security patches either. So every issue below ends with one extra line:

Is this permanent in OSS?

"Upstream will fix it eventually" is no longer an option. Separating what will be fixed from what you must carry forever is what changes your response strategy.

How this post is organized

• Each issue as symptom → cause → diagnosis → response → permanence
• Five areas: design, upgrades, performance, observability, security
• A checklist at the end you can run today

For background and how to choose between the options, see the companion post: MinIO OSS Is Archived — Your Options Alongside AIStor in 2026.

Everything here reflects September 2026. Command options vary by deployed version, so check --help before running anything. That matters more than usual now that versions are frozen.

Part 1. Issues That Harden at Design Time

These are the expensive ones, because decisions made at deployment are effectively irreversible. If you are already in production, only workarounds remain.

1.1 Erasure set layout is irreversible

Symptom — You want to add a few drives and there is no way to do it. Changing node count apparently requires rebuilding the cluster.

Cause — MinIO groups drives into erasure sets at deployment time, and that layout cannot be changed afterwards. Set size and parity level determine that pool's availability and capacity efficiency, and both are fixed at initial deployment. Expansion is only possible by adding a new server pool; you cannot slot individual drives into existing sets.

Diagnosis

# Pool and erasure set layout, drive status
mc admin info myminio
 
# Per-server detail
mc admin info myminio --json | jq '.info.servers[] | {endpoint, drives: (.drives | length)}'

Response

• For a new deployment, spend real time on this decision. Establish your three-year capacity target and node expansion unit first, then work backwards to set size.
• In production, plan expansion exclusively as new server pools. Matching the new pool's configuration to the existing one keeps later operations simple (see 1.3).
• To remove a pool, use mc admin decommission to drain data to other pools before detaching it. This takes a long time and needs its own plan.

Is this permanent in OSS — Yes. It is an architectural design choice rather than a bug, and no development will change it.

1.2 No automatic rebalancing after pool expansion

Symptom — You added a server pool but existing pool utilization has not moved. Only new data lands on the new pool while the old one keeps filling.

Cause — This is intended behavior. MinIO does not automatically redistribute data when a pool is added. Instead it weights new writes by each pool's free space ratio, on the reasoning that rebalancing as a default operation is not effective for object storage.

The design is defensible, but if the existing pool was already near its threshold, weighted new writes resolve it slowly.

Diagnosis

mc admin info myminio
mc admin rebalance status myminio

Response

• Expand well before the existing pool fills. Weighted distribution only works if there is headroom.
• If you need immediate balance, run a manual rebalance — but read 1.4 first.

mc admin rebalance start myminio
mc admin rebalance status myminio

Is this permanent in OSS — Yes. A design decision, not subject to change.

1.3 Different availability SLAs per pool

Symptom — Within one cluster, some objects survive two drive failures and others do not. You cannot predict blast radius during an incident.

Cause — Server pools were configured with different stripe sizes and parity. A pool with an 8-drive stripe at EC:4 has different read and write quorum behavior from one with a 12-drive stripe at EC:4. Fault tolerance depends on which pool an object landed in.

Expanding with whatever hardware happens to be available naturally produces this state.

Diagnosis

mc admin info myminio --json | jq '.info.backend'
mc admin config get myminio storage_class

Response

• Match new pools to the existing configuration. Standardizing your hardware procurement unit is the most reliable way.
• If they are already mixed, set and document your SLA against the weakest pool. The worst case, not the average, is your actual guarantee.
• Consider isolating critical data into separate buckets and reinforcing durability with replication.

Is this permanent in OSS — Yes. A configuration issue that cannot be resolved without redeployment.

1.4 Rebalancing is expensive

Symptom — You started a rebalance and cluster-wide latency degraded. Or it failed with Storage resources are insufficient for the read operation.

Cause — Rebalancing is very resource intensive. It consumes substantial disk I/O and network, competing with normal traffic while it runs. Started without sufficient free space, it can fail outright.

Response

• Never run it during peak hours. Only when cluster usage is at a minimum.
• Ensure ample free space before starting. Rebalancing a full cluster fails or makes things worse.
• It is a long operation — confirm the pause and resume behavior and attach progress monitoring before you start.
• Best of all, expand while you have headroom so rebalancing is never needed.

Is this permanent in OSS — Yes. Any improvements made since have not landed in OSS.

Part 2. Upgrade and Migration Issues

2.1 Gateway and filesystem modes were removed

Symptom — After upgrading, MinIO will not start at all. It errors and exits.

Cause — Gateway mode and filesystem (FS) mode code were fully removed in RELEASE.2022-10-29T06-21-33Z. Deployments on those modes error on startup after upgrading past that release.

The rationale was concrete: core S3 capabilities such as versioning, bucket replication, object locking, and encryption could not be supported in gateway mode without a proprietary backend format.

Diagnosis

mc admin info myminio
minio --version
 
# FS mode is identifiable from the backend format
cat /data/.minio.sys/format.json | jq '.format'

Response

• In-place upgrade is impossible. Create a new Single-Node Single-Drive deployment and migrate settings and data.
• Migrate with mc mirror, but measure first — with a large object count this can take days.

mc mirror --preserve --watch old-minio/bucket new-minio/bucket

Is this permanent in OSS — Yes. Removed functionality is not coming back. If you are still on these modes you have been without security patches for four years, which makes this your highest priority item.

2.2 No zero-downtime rolling updates

Symptom — Upgrading requires stopping the service, which makes upgrades themselves a burden under availability requirements.

Cause — Zero-downtime rolling updates are an AIStor-only capability. OSS has no tree-based binary distribution or version constraint mechanism.

Response

• Secure a maintenance window and treat it as planned downtime.
• With multi-site replication configured, you can upgrade site by site and shift traffic — at the cost of higher configuration complexity and data consistency risk.
• Now that upgrades are no longer frequent, the practical frequency of this issue has ironically dropped.

Is this permanent in OSS — Yes. A commercial differentiator.

2.3 No downgrade path

Symptom — A problem surfaces after upgrading and there is no way back.

Cause — MinIO does not support downgrades. If a newer version changed the backend format or metadata structure, older versions cannot read it.

Response

• Always validate the exact version in staging first.
• Take a backup before production upgrades and rehearse the restore. A procedure that exists only on paper does not exist.
• Plan rollback as "restore from backup," not "revert to the previous version."

Is this permanent in OSS — Yes.

Part 3. Performance and Resource Issues

3.1 Scanner and healing load

Symptom — Disk I/O stays high with no notable traffic. Latency spikes periodically.

Cause — MinIO runs a background scanner that periodically inspects objects and automatically heals those damaged by bitrot or drive failure. Healing also occurs on GET and PUT. The more objects you have, the heavier this becomes.

Diagnosis

mc admin trace myminio
mc admin trace --call heal myminio
mc admin top locks myminio

Response

• Do not run mc admin heal habitually. The command is deprecated and immediately triggers a very resource-intensive full scan. Even after drive replacement or a corruption event it is typically unnecessary — automatic healing handles it.
• If load is the problem, attack the object count itself (see 3.2 and 3.3).
• Plan for the fact that after a drive replacement, performance stays degraded until healing completes.

Is this permanent in OSS — Yes. MinIO states it has applied numerous memory leak, lock contention, and throughput fixes to AIStor, none of which reach OSS. Note that this is a vendor claim with no itemized detail.

3.2 Metadata load from many small objects

Symptom — Capacity is fine but performance is not. Listings are slow and scanner load is high.

Cause — Every object carries metadata, and scanner, healing, and listing costs scale with object count, not bytes. Hundreds of millions of small objects dominate metadata IOPS regardless of total size.

This is especially common in lakehouses, where streaming ingest continuously produces small Parquet files.

Diagnosis

mc du --depth 2 myminio/mybucket
mc ls --recursive --summarize myminio/mybucket | tail -5

Response

• Increase file size at the application layer. This is not a storage tuning problem.
• For a lakehouse, schedule compaction as a routine job. We cover Iceberg table maintenance in Iceberg Table Maintenance with Trino.
• Target file size depends on workload, but if files well under tens of megabytes are accumulating in bulk for analytics, revisit your compaction cadence.

Is this permanent in OSS — Partially. The root fix (compaction, file sizing) lives in your application and is unaffected by the OSS freeze. Storage-engine-level optimization will not arrive.

3.3 Version and delete marker accumulation

Symptom — You deleted data and usage did not drop — it kept growing. Listings get progressively slower.

Cause — On a versioned bucket, a delete adds a delete marker. The data remains. Overwrites retain prior versions. Without lifecycle rules these accumulate indefinitely.

The assumption that mc rm removed something is what produces this situation.

Diagnosis

mc version info myminio/mybucket
mc ls --versions --recursive myminio/mybucket | head -50
mc ilm rule ls myminio/mybucket

Response

Any bucket with versioning enabled must have lifecycle rules alongside it.

# Expire noncurrent versions after 30 days
mc ilm rule add myminio/mybucket \
  --noncurrent-expire-days 30
 
# Clean up expired delete markers
mc ilm rule add myminio/mybucket \
  --expire-delete-marker

Incomplete multipart uploads are another silent consumer. Check them separately from lifecycle.

mc ls --incomplete --recursive myminio/mybucket
mc rm --incomplete --recursive --force myminio/mybucket

Set retention windows to your regulatory and business requirements. Always review the target version list before applying a rule. Lifecycle deletion is irreversible.

Is this permanent in OSS — No. Fully solvable through operational configuration. Check this today.

3.4 Capacity thresholds and procurement lead time

Symptom — Disks fill and writes fail. Expanding means weeks of hardware procurement.

Cause — In object storage, free space is not just storage headroom. Healing, rebalancing, and multipart uploads all require it. A full cluster has lost its ability to recover from failure.

Response

• Set the alert threshold at 80% utilization. That is the point at which an alarm still leaves room for procurement lead time.
• Estimate annual growth and plan capacity ahead. Reactive handling is too late.
• On Kubernetes, consider automating node addition when the threshold is reached.
• Check the easily forgotten consumers: noncurrent versions (3.3), incomplete multipart uploads, delete markers.

Is this permanent in OSS — No. Operational and planning territory, unrelated to the freeze.

Part 4. Observability and Management Issues

4.1 Web console admin features removed

Symptom — After upgrading, user management, policy settings, and bucket deletion are gone from the web console.

Cause — In May 2025 the community edition console lost most administrative capability. What remains is roughly bucket creation and object browsing. It shipped with no advance notice and no warning in the initial changelog, which drove the community backlash.

What went away:

• User management, access policy management
• Bucket deletion, bucket permission settings
• Configuration changes, real-time monitoring, replication controls

Response

The capabilities were not removed — they moved to the mc CLI. Building a mapping table for your common tasks sharply reduces the transition cost.

# Users
mc admin user add myminio newuser
mc admin user list myminio
mc admin user disable myminio olduser
 
# Policies
mc admin policy create myminio mypolicy ./policy.json
mc admin policy attach myminio mypolicy --user newuser
mc admin policy list myminio
 
# Bucket policy
mc anonymous set download myminio/public-bucket
mc anonymous get myminio/public-bucket
 
# Replication
mc replicate ls myminio/mybucket
mc replicate status myminio/mybucket

Recommended actions

• Rewrite console-dependent runbooks against the CLI
• If non-engineering staff used the console, provide an alternative path (internal tooling or an approval workflow)
• Wrap frequent mc commands in scripts to reduce room for mistakes

Is this permanent in OSS — Yes. It is not coming back.

4.2 You must build monitoring yourself

Symptom — With the console's real-time monitoring gone, there is nowhere to see cluster state.

Cause — The console reduction removed the web-based monitoring path. The Prometheus metrics endpoint is still there, so you build it yourself.

Response

mc admin prometheus generate myminio
mc admin prometheus generate myminio --json

Feed that into Prometheus, attach Grafana, and you end up with better observability than the console offered. Start from MinIO's documented default Alertmanager rules and extend for your environment.

Minimum alerts to configure

Is this permanent in OSS — No. The metrics endpoint is alive; self-built observability covers this fully.

4.3 Replication lag blind spot

Symptom — Replication to the DR site falls behind and you find out much later.

Cause — Replication is asynchronous and lag itself is normal. The problem is that there is no defined limit for acceptable lag and nothing alerts you by default. With replication controls gone from the console, the visual check disappeared too.

Diagnosis

mc replicate status myminio/mybucket
mc admin replicate info myminio

Response

• Define an RPO target as a number and alert against it. What you observe is not "replication is running" but "replicated within N minutes."
• Run actual recovery drills periodically. A green replication status does not prove recovery works.

Is this permanent in OSS — No. Addressable through observability and operational design.

Part 5. Security and Compliance Issues

This is the most serious area. The other issues have workarounds; these largely do not.

5.1 Security patches have stopped

Symptom — Your vulnerability scanner flags MinIO and there is no version to upgrade to.

Cause — Repository archival ended all fixes, security fixes included. Vulnerabilities discovered from here remain permanently open in the community edition.

MinIO states it applied 47+ critical fixes to AIStor, but no CVE identifiers and no individual vulnerability descriptions have been published. That is particularly awkward for defenders — you cannot even tell what you are exposed to.

Response — mitigation only

• Minimize network exposure — remove direct internet exposure, separate management ports, restrict source IPs
• Re-audit least privilege — clean up over-permissioned users and service accounts
• Add a defense layer with a reverse proxy or WAF in front
• Strengthen audit log collection and anomalous access detection
• Track vulnerability disclosures actively — no vendor will tell you

Is this permanent in OSS — Yes, and it worsens over time. Unlike the other issues, this risk grows if you do nothing. If you run internet-facing MinIO OSS, this item alone justifies evaluating migration.

5.2 Supply chain responsibility from source-only distribution

Symptom — You need to deploy a new node and there is no binary to fetch. An audit asks where your binary came from and who verified it, and you cannot answer.

Cause — The community edition is distributed as source only. Existing binaries remain on GitHub Releases and dl.min.io but are not updated.

Response

go install github.com/minio/minio@latest
 
# Or pin a specific commit for reproducibility
go install github.com/minio/minio@<commit-sha>

The build itself is the easy part; the surrounding procedure is the real burden.

• Mirror a source snapshot internally so you can still build if upstream disappears
• Pin the Go toolchain and establish reproducible builds
• Sign build outputs and store them in an internal artifact repository
• Add SBOM generation and vulnerability scanning to the pipeline
• Build, scan, and sign container images in-house
• Record the exact version and hash of your production binary

Is this permanent in OSS — Yes. But the procedures above bring it down to a manageable level.

5.3 Compliance requirements cannot be met

Symptom — An audit requires FIPS-validated cryptography and you cannot satisfy it.

Cause — FIPS 140-3 validated cryptography is AIStor-only. Separately, in regulatory environments that require "supported software," an archived project is difficult to justify.

Response

• If the requirement is real, there is no workaround. AIStor or a certified alternative.
• Confirm this ahead of the audit. Migration under audit-finding deadline pressure is far more expensive.

Is this permanent in OSS — Yes.

Part 6. A Checklist to Run Now

Ordered by priority. Work top down.

Today

• Confirm your exact deployed version — mc admin info / minio --version
• Check internet exposure. If exposed, 5.1 is your top priority
• Check whether you use gateway or FS mode (2.1) — if so you have a four-year patch gap
• Archive your production binary internally (you can no longer fetch it)

This week

• Review lifecycle rules on versioned buckets (3.3) — configure them now if absent
• Confirm cleanup for incomplete multipart uploads
• Verify the 80% disk utilization alert (3.4)
• Review Prometheus metrics collection and alerting (4.2)
• Check erasure configuration consistency across pools (1.3); if mixed, document your real SLA at the weakest level

This month

• Mirror source internally and build a build pipeline (5.2)
• Rewrite console-dependent runbooks against the CLI (4.1)
• Rehearse backup and restore — if you have only documented it, you have not done it
• Set a replication RPO target and alerting (4.3)
• Build a three-year capacity plan and pool expansion design (1.1, 1.2)

Quarterly

• Re-evaluate your options — stay, AIStor, or migrate. See the decision tree in the comparison post
• Re-grade exposure and risk
• Review vulnerability disclosure tracking

Summary

MinIO OSS issues fall into three groups, and each calls for a different strategy.

If even one item in the third group applies to you, that item sets your decision deadline. No amount of diligence on the others makes it go away.

Start with the first group. Whatever you choose, the risk before migration still has to come down — and lifecycle, monitoring, and backup hygiene carry over to whatever storage you land on.

References

• minio/minio GitHub repository — archival notice, source-only distribution
• mc admin heal reference — deprecated status
• Deprecation of the MinIO gateway
• No More Default Rebalancing of Object Storage
• Manually Rebalance your MinIO Modern Datalake
• Critical WEB UI features removed in Community Edition (Issue #21584)

If you need a MinIO cluster assessment, risk evaluation, or migration design, get in touch.