Skip to content

MinIO Image Pull Failure

The minio/minio image is no longer available from Docker Hub. Kubernetes cannot start a new MinIO pod from that image, so a pod restart or reschedule (or a helm upgrade for Component Pack) fails with ErrImagePull or ImagePullBackOff.

MinIO is discontinued: migrate to SeaweedFS

MinIO no longer publishes community releases or security fixes. Boards now uses SeaweedFS for S3 storage. The workaround on this page only keeps MinIO running while you migrate. It is not a long-term fix: MinIO can also remove its images from Quay.io at any time.

Follow the SeaweedFS migration guide now.

Check if you are affected

You are affected if you deploy MinIO with one of these:

  • The huddo-boards-cp Helm chart (all versions to 2.4.0) with MinIO enabled. MinIO is enabled unless your values file sets minio.enabled: false.
  • The standalone minio.yaml for Kubernetes.

Look for a MinIO pod that is not running:

kubectl get pods --all-namespaces | grep minio
kubectl describe pod <minio-pod-name> --namespace <namespace>

The events show a failed pull of docker.io/minio/minio.

Component Pack (huddo-boards-cp)

Temporary workaround

  1. Point the MinIO deployment at the same image on Quay.io. It is the same MinIO version that the chart uses, so your data does not change:

    kubectl set image deployment/huddo-boards-cp-minio minio=quay.io/minio/minio:RELEASE.2022-10-24T18-35-07Z --namespace connections

    Replace connections with your Boards namespace if it is different (see kubectl get pods --all-namespaces | grep minio).

  2. Make sure that the pod starts:

    kubectl rollout status deployment/huddo-boards-cp-minio --namespace connections

Run the command again after every helm upgrade

helm upgrade sets the image back to Docker Hub. The MinIO pod that is running stays up, but Kubernetes cannot start a replacement pod. Run kubectl set image again immediately after each helm upgrade, including the upgrades in the SeaweedFS migration.

If you installed the release with Helm 4, helm upgrade stops with conflict with "kubectl-set". Add --force-conflicts to the helm upgrade command, then run kubectl set image again.

Note

Loading the image onto your nodes yourself does not help. The chart sets imagePullPolicy: Always, so Kubernetes always pulls from the registry.

Migrate to SeaweedFS

Follow the SeaweedFS migration guide. The migration needs chart huddo-boards-cp v2.1.0 or later. If your chart is older, upgrade to the latest chart as part of Phase 1 of the migration guide, with the Phase 1 values (including S3_BUCKET: kudos-boards), so that Boards keeps your existing attachments. Read the Breaking Changes column first: v2.0.0 moves to Traefik. Run kubectl set image again after that upgrade.

After the cutover (minio.enabled: false), MinIO is removed and you do not need this workaround.

Standalone Kubernetes (minio.yaml)

Temporary workaround

  1. In your minio.yaml, change the MinIO container image:

    containers:
  - name: minio
    image: quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z

    RELEASE.2025-09-07T16-13-09Z is the last MinIO image that was published as latest.

  2. Apply the file:

    kubectl apply -f ./minio.yaml

Migrate to SeaweedFS

Deploy SeaweedFS, then copy your data from MinIO with rclone sync, as shown in the manual migration command. Use http://minio-service:9000 as the source endpoint and your SeaweedFS service as the destination. Then change S3_ENDPOINT in your boards.yaml to SeaweedFS and upgrade Boards.

If you need help, email support@huddo.com.