Hands-on Lab

How to Fix the MinIO pull access denied Error in Docker

October 21, 2026 4 min 1

0 / 8

Cheat sheet

Found it useful? Don't miss the next lab

The video has captions and a transcript. Everything it shows is written out, step by step, below. Cheat sheet with every command

0:00 / 0:00

We ask Docker Hub for the official MinIO image, the default latest tag. The daemon answers pull access denied for minio/minio and exits with code 1: the repository does not exist or requires a login.

docker pull minio/minio

I did it

We ask the public Docker Hub API for both repositories. minio/minio and minio/mc answer 404 with object not found, while the minio namespace still lists 20 other repositories: the image was deleted, this is not a credentials problem.

curl -s -w '\nminio/minio: HTTP %{http_code}\n' https://hub.docker.com/v2/repositories/minio/minio/; curl -s -o /dev/null -w 'minio/mc: HTTP %{http_code}\n' https://hub.docker.com/v2/repositories/minio/mc/; curl -s 'https://hub.docker.com/v2/repositories/minio/?page_size=100' | jq -r '"repositories under minio: \(.count)"'

What this proves

"message":"object not found" Docker Hub answers that the minio/minio repository does not exist Goal · you rule out docker login as a fix: there is nothing left to pull
minio/mc: HTTP 404 the minio/mc client no longer exists on Docker Hub either Goal · you know the mc client image needs a replacement too

We try the quay.io alternative with the RELEASE.2025-09-07T16-13-09Z tag, the one this blog's MinIO install guide pinned. Quay refuses the anonymous pull with unauthorized and the command exits with code 1 again.

docker pull quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z

I did it

We read the manifest of cgr.dev/chainguard/minio and cgr.dev/chainguard/minio-client without pulling any layer. Both publish linux/amd64 and linux/arm64, so the switch works on an x86 server and on a Raspberry Pi or an Apple Silicon Mac.

for img in minio minio-client; do echo "cgr.dev/chainguard/$img:latest"; docker manifest inspect cgr.dev/chainguard/$img:latest | jq -r '.manifests[].platform | "  \(.os)/\(.architecture)"'; done

What this proves

linux/arm64 the Chainguard image ships an arm64 variant Goal · you know the replacement pulls without an account and on your architecture
linux/amd64 the same tag also publishes the amd64 variant Goal · you can use the same compose file on an x86 server

We create /lab with a throwaway .env (labadmin / changeme) and a compose.yaml that only changes the image: line to cgr.dev/chainguard/minio:latest. The usual command works because the entrypoint is already the minio binary, and ports 9000 (S3 API) and 9001 (console) stay on 127.0.0.1.

mkdir -p /lab && cd /lab && printf 'MINIO_ROOT_USER=labadmin\nMINIO_ROOT_PASSWORD=changeme\n' > .env && cat > compose.yaml <<'EOF'
services:
  minio:
    image: cgr.dev/chainguard/minio:latest
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: ${MINIO_ROOT_USER}
      MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:9000:9000"
      - "127.0.0.1:9001:9001"
    restart: unless-stopped
EOF
docker compose up -d --quiet-pull

I did it

We wait for MinIO to log its error and read it. Docker created the data directory as root (0 0), the image declares user 65532 and MinIO stops with file access denied and FATAL Unable to initialize backend. It is the error the guide describes when you leave the official image, which ran as root.

cd /lab && for i in $(seq 1 30); do docker compose logs minio 2>&1 | grep -q FATAL && break; sleep 2; done; ls -lnd data; docker image inspect --format 'image user: {{.Config.User}}' cgr.dev/chainguard/minio:latest; docker compose logs --no-log-prefix minio 2>&1 | grep -m1 'file access denied'; docker compose logs --no-log-prefix minio 2>&1 | grep -m1 FATAL

What this proves

image user: 65532 the Chainguard image runs MinIO as user 65532, not as root Goal · you understand why a root-owned directory stops working after the image switch
FATAL Unable to initialize backend MinIO cannot write to /data and stops while initialising the storage Goal · you recognise the symptom in your own logs before you change anything

We stop the service with docker compose down and run chown -R 65532:65532 on /data from busybox:1.37, pulled from Google's mirror so we do not depend on Docker Hub. Then we bring it up again. No sudo is needed on the host because the chown runs inside the container.

cd /lab && docker compose down && docker run --rm -v "$PWD/data:/data" mirror.gcr.io/library/busybox:1.37 chown -R 65532:65532 /data && docker compose up -d

I did it

We wait for /minio/health/live to answer. The data directory now belongs to 65532:65532, the liveness probe returns HTTP 200 and the startup log shows the RELEASE version of the Chainguard fork.

cd /lab && for i in $(seq 1 60); do curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:9000/minio/health/live | grep -q 200 && break; sleep 2; done; ls -lnd data; curl -s -o /dev/null -w 'health/live: HTTP %{http_code}\n' http://127.0.0.1:9000/minio/health/live; docker compose logs --no-log-prefix minio 2>&1 | grep -m1 'Version:'

What this proves

65532 65532 the data directory now belongs to user and group 65532 Goal · you confirm the chown reached the bind mount the container uses
health/live: HTTP 200 MinIO's liveness probe answers 200 OK Goal · you know the S3 server is up on the new image
Version: RELEASE. the binary reports a RELEASE version, not a development build Goal · you have a version reference to track its security advisories

We create a test file and a /usr/local/bin/mc wrapper that runs the client image on the lab_default network, with MC_CONFIG_DIR mounted on /lab/mc. We load the .env and register the local alias against http://minio:9000, but mc cannot save its config: permission denied.

mkdir -p /lab/mc /lab/files && echo 'jacar.es MinIO lab' > /lab/files/test.txt && cat > /usr/local/bin/mc <<'EOF'
#!/bin/sh
exec docker run --rm --network lab_default -v /lab/mc:/tmp/mc -e MC_CONFIG_DIR=/tmp/mc -v /lab/files:/files:ro cgr.dev/chainguard/minio-client:latest "$@"
EOF
chmod +x /usr/local/bin/mc && docker pull -q cgr.dev/chainguard/minio-client:latest && . /lab/.env && mc alias set local http://minio:9000 "$MINIO_ROOT_USER" "$MINIO_ROOT_PASSWORD"

I did it

The Chainguard client also runs as user 65532 and /lab/mc belonged to root. We change its owner with chown 65532:65532 and repeat mc alias set: this time it answers Added local successfully.

chown 65532:65532 /lab/mc && . /lab/.env && mc alias set local http://minio:9000 "$MINIO_ROOT_USER" "$MINIO_ROOT_PASSWORD"

I did it

We check the alias with mc ready, which asks the server whether it accepts requests, and with mc alias list, which shows the URL and access key stored in MC_CONFIG_DIR.

mc ready local; mc alias list local | head -3

What this proves

The cluster 'local' is ready the MinIO server answers the mc client and accepts requests Goal · you know the Chainguard client replaces minio/mc
http://minio:9000 the local alias points to the minio service on the compose network Goal · you can use the same alias in scripts that used to call minio/mc

We create the lab-bucket bucket with mc mb and copy test.txt into it with mc cp. It is what a typical bootstrap script in a MinIO compose setup does, now with the Chainguard client.

mc mb local/lab-bucket && mc cp /files/test.txt local/lab-bucket/

I did it

We list the bucket, read the object and compare its SHA-256 sum with the original file: they match. The last ls shows the object inside ./data owned by 65532, on the same bind mount we fixed.

mc ls local/lab-bucket; mc cat local/lab-bucket/test.txt; [ "$(mc cat local/lab-bucket/test.txt | sha256sum | cut -d' ' -f1)" = "$(sha256sum < /lab/files/test.txt | cut -d' ' -f1)" ] && echo 'sha256: identical'; ls -ln /lab/data/lab-bucket/

What this proves

STANDARD test.txt the lab-bucket bucket holds the test.txt object Goal · you check MinIO stores objects again after the image error
sha256: identical the downloaded object has the same SHA-256 sum as the original Goal · you know the content round-trips intact, not just that the name exists

We remove the service and the lab_default network with docker compose down and delete /lab, with the data, the .env and the mc config, plus the /usr/local/bin/mc wrapper.

cd /lab && docker compose down && rm -rf /lab /usr/local/bin/mc

I did it

We check that no lab-minio container is left, that the lab_default network is gone and that /lab was deleted.

docker ps -a --filter name=lab-minio --format '{{.Names}}'; docker network ls --filter name=lab_default --format '{{.Name}}'; test -e /lab || echo 'no /lab directory left'

What this proves

no /lab directory left the lab directory no longer exists Goal · you leave the machine as it was before you started

1 view

Was this lab useful? Rate it:

Click to rate this post!

[Total: 0 Average: 0]

Video transcript

0:00 This is how MinIO works again in Docker after the pull access denied error.
0:06 We start with the failure:
0:08 docker pull minio/minio returns pull access denied, the same error you get when
0:13 a compose file uses that image.
0:16 Docker prints the same message for a private repository and for one that no
0:20 longer exists.
0:21 We fix MinIO's pull access denied error by switching images and prove it with a real
0:27 bucket.
0:28 We cover the failure, the API proof, the new image, the permission error, its fix
0:33 and the mc client.
0:34 The Docker Hub API confirms the cause:
0:37 minio/minio and minio/mc return 404, while the minio namespace still
0:43 lists 20 other repositories.
0:46 The quay.io copy does not help either:
0:49 the release our install guide pinned answers unauthorized without an account.
0:54 The replacement is the Chainguard image:
0:56 its manifest publishes amd64 and arm64, for the server and the client.
1:03 We write the compose file with the Chainguard image, the credentials in a
1:08 .env file and the data in ./data, and we bring it up.
1:12 But MinIO does not start:
1:14 the image runs as user 65532, ./data belongs
1:20 to root and the log ends in file access denied.
1:24 65532 is the unprivileged user in Chainguard images; your
1:30 data has to belong to it.
1:32 The fix:
1:33 we stop the service, change the owner of ./data to
1:37 65532 from a throwaway busybox container and bring it back up.
1:43 Now it works:
1:44 ./data belongs to 65532, the health/live probe
1:50 answers 200 and the log shows the MinIO RELEASE version that started.
1:55 For the client we use cgr.dev/chainguard/minio-client on the
2:00 compose network.
2:02 The first alias set fails:
2:04 it cannot save its config.
2:06 mc also runs as 65532, so its config folder has to belong
2:12 to it.
2:13 It is the same problem as with the data:
2:15 mc runs as 65532.
2:19 We give /lab/mc to that user and the alias is saved.
2:24 mc ready confirms the local server is ready and the alias points to
2:28 http://minio:9000 with the labadmin user.
2:33 We create the lab-bucket bucket with mc mb and upload the test file with mc cp.
2:40 mc ls lists test.txt, mc cat returns its content, the sha256
2:47 sum matches and the object sits in ./data.
2:50 We clean up:
2:51 we take the compose stack down and delete /lab and the mc wrapper.
2:58 We check it:
2:58 no lab container or network is left, and no /lab directory.

This lab replays in a real terminal the guide to fixing pull access denied for minio/minio in Docker: the error appears because the minio/minio image no longer exists on Docker Hub, and the fix is a different image, not docker login. We recorded it on 21 October 2026 on Debian 13 with Docker inside, on arm64.

What the capture proves

Every claim in the video comes from real output. docker pull minio/minio exits with code 1, the Docker Hub API answers 404 for minio/minio and minio/mc, and quay.io/minio/minio refuses the anonymous pull. Then we bring up cgr.dev/chainguard/minio:latest with Docker Compose, reproduce the permission failure, fix it with chown -R 65532:65532 and check the result with /minio/health/live and the mc client.

The exact error text changes with the Docker version. Our daemon, Debian’s docker.io, appends denied: requested access to the resource is denied, and Quay answers unauthorized instead of the 401 UNAUTHORIZED shown in the guide. The cause is the same: the docker pull reference explains that a private repository and a missing one look identical.

Why the Chainguard image needs a chown

The official MinIO image ran as root and the Chainguard MinIO image runs as user 65532. A bind mount such as ./data keeps the owner from the host, so MinIO stops with file access denied and FATAL Unable to initialize backend. To review how mounts work, the lab on volumes and bind mounts in Docker walks through it step by step.

Pitfalls I ran into

These are the four that came up while recording the lab:

The data directory: Docker creates ./data as root when it does not exist, and user 65532 cannot write to it. A chown from a busybox container fixes it without sudo
The mc config: the cgr.dev/chainguard/minio-client client also runs as 65532. With MC_CONFIG_DIR mounted on a root-owned folder, mc alias set fails with permission denied, and we fix it with chown 65532:65532 /lab/mc
Only the latest tag exists: Chainguard publishes no per-version tags on its free plan. Pin the image by sha256 digest if you need reproducible builds
No curl or wget in the image: a healthcheck that calls them fails. The guide to healthchecks in Docker Compose explains how to design one, and here we probe from outside with curl

Other ways out we did not record

The original guide tests two more replacements: the pgsty/silo fork, with per-version tags and running as root, and your own image built from the archived MinIO repository with a 22-line Dockerfile. We did not build MinIO in the lab because it takes several minutes and adds nothing visible in a terminal; the Dockerfile and its output are in the guide.

Switching images brings MinIO back to life, but the upstream code is archived. If you set it up with the guide to installing MinIO with Docker, consider the migration from MinIO to Garage, the lightweight option, or the migration to RustFS, the closest to MinIO. For an image registry that does not depend on Docker Hub, see the lab on the private, self-hosted Docker registry.

FAQ

No. The Docker Hub API answers 404 for minio/minio and minio/mc: the repositories were deleted. Docker suggests docker login because it prints the same message for a private repository and for a missing one. The way out is changing the image: line in your compose file.

Why does MinIO stop with file access denied on the Chainguard image?

Because that image runs as user 65532 and your data directory belongs to root, as the official image left it. Stop the service, run chown -R 65532:65532 on the data from a throwaway container and start it again.

Which image should I use for the mc client now that minio/mc is gone?

cgr.dev/chainguard/minio-client:latest, whose entrypoint is already mc. It runs as 65532, so mount MC_CONFIG_DIR on a folder owned by that user or mc alias set fails with permission denied.

Can I build MinIO from source instead of using Chainguard?

Yes. The original guide includes a 22-line Dockerfile that builds MinIO RELEASE.2025-10-15T17-29-55Z and mc into an Alpine image. We did not record it in this lab because the build takes several minutes; patches become your job.

Cheat sheet

```
docker pull minio/minio
```

docker pull quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z

mkdir -p /lab && cd /lab && printf 'MINIO_ROOT_USER=labadmin\nMINIO_ROOT_PASSWORD=changeme\n' > .env && cat > compose.yaml <<'EOF'
services:
  minio:
    image: cgr.dev/chainguard/minio:latest
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: ${MINIO_ROOT_USER}
      MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:9000:9000"
      - "127.0.0.1:9001:9001"
    restart: unless-stopped
EOF
docker compose up -d --quiet-pull

cd /lab && docker compose down && docker run --rm -v "$PWD/data:/data" mirror.gcr.io/library/busybox:1.37 chown -R 65532:65532 /data && docker compose up -d

mkdir -p /lab/mc /lab/files && echo 'jacar.es MinIO lab' > /lab/files/test.txt && cat > /usr/local/bin/mc <<'EOF'
#!/bin/sh
exec docker run --rm --network lab_default -v /lab/mc:/tmp/mc -e MC_CONFIG_DIR=/tmp/mc -v /lab/files:/files:ro cgr.dev/chainguard/minio-client:latest "$@"
EOF
chmod +x /usr/local/bin/mc && docker pull -q cgr.dev/chainguard/minio-client:latest && . /lab/.env && mc alias set local http://minio:9000 "$MINIO_ROOT_USER" "$MINIO_ROOT_PASSWORD"

chown 65532:65532 /lab/mc && . /lab/.env && mc alias set local http://minio:9000 "$MINIO_ROOT_USER" "$MINIO_ROOT_PASSWORD"

mc mb local/lab-bucket && mc cp /files/test.txt local/lab-bucket/

cd /lab && docker compose down && rm -rf /lab /usr/local/bin/mc

Found it useful? Don't miss the next lab

Subscribe to the newsletter

What the capture proves

Why the Chainguard image needs a chown

Pitfalls I ran into

Other ways out we did not record

FAQ

Does docker login fix the MinIO pull access denied error?

Why does MinIO stop with file access denied on the Chainguard image?

Which image should I use for the mc client now that minio/mc is gone?

Can I build MinIO from source instead of using Chainguard?

Cheat sheet