Hands-on Lab

Cómo arreglar el error pull access denied de MinIO en Docker

21 de octubre de 2026 4 min 1

0 / 8

Chuleta

¿Te ha servido? No te pierdas el próximo lab

El vídeo tiene subtítulos y transcripción. Todo lo que se ve está escrito, paso a paso, más abajo. Chuleta con todos los comandos

0:00 / 0:00

Pedimos la imagen oficial de MinIO a Docker Hub, la etiqueta latest por defecto. El demonio responde pull access denied for minio/minio y termina con código 1: el repositorio no existe o exige iniciar sesión.

docker pull minio/minio

Lo hice yo

Preguntamos a la API pública de Docker Hub por los dos repositorios. minio/minio y minio/mc responden 404 con object not found, mientras que el espacio minio sigue listando otros 20 repositorios: la imagen se borró, no es un problema de credenciales.

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)"'

Qué demuestra

"message":"object not found" Docker Hub contesta que el repositorio minio/minio no existe Objetivo · descartas que docker login vaya a arreglarlo: no hay nada que descargar
minio/mc: HTTP 404 el cliente minio/mc tampoco existe ya en Docker Hub Objetivo · sabes que también tendrás que sustituir la imagen del cliente mc

Probamos la alternativa de quay.io con la etiqueta RELEASE.2025-09-07T16-13-09Z, la que fijaba la guía para instalar MinIO de este blog. Quay rechaza la descarga anónima con unauthorized y el comando vuelve a terminar con código 1.

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

Lo hice yo

Leemos el manifiesto de cgr.dev/chainguard/minio y cgr.dev/chainguard/minio-client sin descargar capas. Los dos publican linux/amd64 y linux/arm64, así que el cambio funciona en un servidor x86 y en una Raspberry Pi o un Mac con Apple Silicon.

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

Qué demuestra

linux/arm64 la imagen de Chainguard tiene variante para arm64 Objetivo · sabes que el sustituto se descarga sin cuenta y en tu arquitectura
linux/amd64 la misma etiqueta publica también la variante amd64 Objetivo · puedes usar el mismo compose en un servidor x86

Creamos /lab con un .env de prueba (labadmin / changeme) y un compose.yaml que solo cambia la línea image: por cgr.dev/chainguard/minio:latest. El command de siempre funciona porque el punto de entrada ya es el binario minio, y los puertos 9000 (API S3) y 9001 (consola) quedan en 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

Lo hice yo

Esperamos a que MinIO escriba su error y lo leemos. El directorio data lo creó Docker como root (0 0), la imagen declara el usuario 65532 y MinIO se para con file access denied y FATAL Unable to initialize backend. Es el error que describe la guía al pasar de la imagen oficial, que corría como 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

Qué demuestra

image user: 65532 la imagen de Chainguard ejecuta MinIO con el usuario 65532, no con root Objetivo · entiendes por qué un directorio de root deja de servir al cambiar de imagen
FATAL Unable to initialize backend MinIO no puede escribir en /data y se detiene al iniciar el almacenamiento Objetivo · reconoces el síntoma en tus propios registros antes de tocar nada

Bajamos el servicio con docker compose down, ejecutamos chown -R 65532:65532 sobre /data desde busybox:1.37, descargada del espejo de Google para no depender de Docker Hub, y lo levantamos otra vez. No hace falta sudo en el host porque el chown corre dentro del contenedor.

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

Lo hice yo

Esperamos a que /minio/health/live responda. El directorio data pertenece ahora a 65532:65532, la sonda de vida devuelve HTTP 200 y el registro del arranque muestra la versión RELEASE del fork de Chainguard.

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:'

Qué demuestra

65532 65532 el directorio de datos pertenece ahora al usuario y grupo 65532 Objetivo · confirmas que el chown llegó al bind mount que usa el contenedor
health/live: HTTP 200 la sonda de vida de MinIO responde 200 OK Objetivo · sabes que el servidor S3 está en marcha con la imagen nueva
Version: RELEASE. el binario se identifica como una versión RELEASE, no como una compilación de desarrollo Objetivo · tienes una referencia de versión para seguir sus avisos de seguridad

Creamos un fichero de prueba y un envoltorio /usr/local/bin/mc que ejecuta la imagen del cliente en la red lab_default, con MC_CONFIG_DIR montado en /lab/mc. Cargamos el .env y registramos el alias local contra http://minio:9000, pero mc no puede guardar su configuración: 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"

Lo hice yo

El cliente de Chainguard también corre como el usuario 65532 y /lab/mc pertenecía a root. Cambiamos su propietario con chown 65532:65532 y repetimos mc alias set: esta vez responde Added local successfully.

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

Lo hice yo

Comprobamos el alias con mc ready, que pregunta al servidor si acepta peticiones, y con mc alias list, que muestra la URL y la clave de acceso guardadas en MC_CONFIG_DIR.

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

Qué demuestra

The cluster 'local' is ready el servidor MinIO responde al cliente mc y acepta peticiones Objetivo · sabes que el cliente de Chainguard sustituye a minio/mc
http://minio:9000 el alias local apunta al servicio minio de la red del compose Objetivo · puedes usar el mismo alias en los scripts que antes llamaban a minio/mc

Creamos el bucket lab-bucket con mc mb y copiamos en él test.txt con mc cp. Es lo que hace el script de arranque típico de un compose con MinIO, ahora con el cliente de Chainguard.

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

Lo hice yo

Listamos el bucket, leemos el objeto y comparamos su suma SHA-256 con la del fichero original: coinciden. El último ls muestra el objeto dentro de ./data con propietario 65532, en el mismo bind mount que arreglamos.

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/

Qué demuestra

STANDARD test.txt el bucket lab-bucket contiene el objeto test.txt Objetivo · compruebas que MinIO guarda objetos de nuevo tras el error de la imagen
sha256: identical el objeto descargado tiene la misma suma SHA-256 que el original Objetivo · sabes que el contenido llega íntegro, no solo que el nombre existe

Bajamos el servicio y la red lab_default con docker compose down y borramos /lab, con los datos, el .env y la configuración de mc, y el envoltorio /usr/local/bin/mc.

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

Lo hice yo

Comprobamos que no queda ningún contenedor lab-minio, que la red lab_default ya no existe y que /lab se ha borrado.

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'

Qué demuestra

no /lab directory left el directorio del lab ya no existe Objetivo · dejas la máquina como estaba antes de empezar

1 vista

¿Te ha sido útil este lab? Puntúalo:

Click to rate this post!

[Total: 0 Average: 0]

Transcripción del vídeo

0:01 Así vuelve a funcionar MinIO en Docker tras el error pull access denied.
0:06 Empezamos por el fallo:
0:08 docker pull minio/minio devuelve pull access denied, el mismo error que ves al
0:14 levantar un compose con esa imagen.
0:17 Docker usa el mismo mensaje para un repositorio privado y para uno que ya no
0:21 existe.
0:23 Arreglamos el error pull access denied de MinIO cambiando de imagen y lo demostramos
0:28 con un bucket real.
0:31 Veremos el fallo, la prueba en la API, la imagen nueva, el error de permisos, su
0:37 arreglo y el cliente mc.
0:40 La API de Docker Hub confirma la causa:
0:43 minio/minio y minio/mc devuelven 404, aunque el espacio minio publica otros 20
0:49 repositorios.
0:51 La copia de quay.io tampoco sirve:
0:54 la versión que fijaba nuestra guía de instalación responde unauthorized sin una
0:59 cuenta.
1:01 El sustituto es la imagen de Chainguard:
1:04 su manifiesto publica amd64 y arm64, para el servidor y para
1:10 el cliente.
1:12 Escribimos el compose con la imagen de Chainguard, las credenciales en un fichero
1:17 .env y los datos en ./data, y lo levantamos.
1:22 Pero MinIO no arranca:
1:24 la imagen corre como el usuario 65532, ./data pertenece a root y el
1:30 registro termina en file access denied.
1:34 65532 es el usuario sin privilegios de las imágenes de Chainguard; tus datos
1:40 tienen que ser suyos.
1:43 El arreglo:
1:44 paramos el servicio, cambiamos el propietario de ./data a
1:48 65532 desde un contenedor busybox desechable y volvemos a
1:54 levantarlo.
1:55 Ahora sí:
1:56 ./data pertenece a 65532, la sonda health/live
2:02 responde 200 y el registro muestra la versión RELEASE de MinIO que arrancó.
2:09 Para el cliente usamos cgr.dev/chainguard/minio-client en la red
2:14 del compose.
2:15 El primer alias set falla:
2:17 no puede guardar su configuración.
2:19 mc también corre como 65532, así que su carpeta de
2:25 configuración tiene que ser suya.
2:28 Es el mismo problema que con los datos:
2:31 mc corre como 65532.
2:34 Damos /lab/mc a ese usuario y el alias se guarda.
2:39 mc ready confirma que el servidor local está listo y el alias apunta a
2:43 http://minio:9000 con el usuario labadmin.
2:48 Creamos el bucket lab-bucket con mc mb y subimos el fichero de prueba con
2:54 mc cp.
2:56 mc ls lista test.txt, mc cat devuelve su contenido, la
3:02 suma sha256 coincide y el objeto está en ./data.
3:08 Limpiamos:
3:09 bajamos el compose y borramos /lab y el envoltorio de mc.
3:14 Lo comprobamos:
3:15 no queda contenedor ni red del lab, ni el directorio /lab.

Este laboratorio reproduce en una terminal real la guía para arreglar pull access denied for minio/minio en Docker: el error aparece porque la imagen minio/minio ya no existe en Docker Hub, y se arregla cambiando de imagen, no con docker login. Lo grabamos el 21 de octubre de 2026 en un Debian 13 con Docker dentro, sobre arm64.

Qué demuestra la captura

Cada afirmación del vídeo sale de una salida real. docker pull minio/minio termina con código 1, la API de Docker Hub responde 404 a minio/minio y a minio/mc, y quay.io/minio/minio rechaza la descarga anónima. Después levantamos cgr.dev/chainguard/minio:latest con Docker Compose, reproducimos el fallo de permisos, lo arreglamos con chown -R 65532:65532 y comprobamos el resultado con /minio/health/live y con el cliente mc.

El texto exacto del error cambia con la versión de Docker. Nuestro demonio, el docker.io de Debian, añade denied: requested access to the resource is denied al final, y Quay responde unauthorized en lugar del 401 UNAUTHORIZED que muestra la guía. La causa es la misma: lo explica la referencia de docker pull, que trata igual un repositorio privado y uno inexistente.

Por qué la imagen de Chainguard necesita un chown

La imagen oficial de MinIO corría como root y la de Chainguard para MinIO corre como el usuario 65532. Un bind mount como ./data conserva el propietario del host, así que MinIO se para con file access denied y FATAL Unable to initialize backend. Si quieres repasar cómo funcionan los montajes, el laboratorio de volúmenes y bind mounts en Docker lo enseña paso a paso.

Dificultades con las que me he topado

Estas son las cuatro que aparecieron al grabar el laboratorio:

El directorio de datos: Docker crea ./data como root si no existe, y el usuario 65532 no puede escribir en él. El chown desde un contenedor busybox lo arregla sin sudo
La configuración de mc: el cliente cgr.dev/chainguard/minio-client también corre como 65532. Con MC_CONFIG_DIR montado en una carpeta de root, mc alias set falla con permission denied; lo arreglamos con chown 65532:65532 /lab/mc
Solo existe la etiqueta latest: Chainguard no publica etiquetas por versión en su plan gratuito. Fija la imagen por resumen sha256 si necesitas builds reproducibles
No hay curl ni wget en la imagen: un healthcheck que los llame falla. La guía de healthchecks en Docker Compose explica cómo plantearlo, y aquí comprobamos la sonda desde fuera con curl

Otras salidas que no grabamos

La guía original prueba dos sustitutos más: el fork pgsty/silo, con etiquetas por versión y que corre como root, y una imagen propia compilada desde el repositorio archivado de MinIO con un Dockerfile de 22 líneas. No compilamos MinIO en el laboratorio porque tarda varios minutos y no añade nada que se vea en una terminal; el Dockerfile y su salida están en la guía.

Cambiar de imagen devuelve MinIO a la vida, pero el código de upstream está archivado. Si lo montaste con la guía para instalar MinIO con Docker, valora la migración de MinIO a Garage, la opción ligera, o la migración a RustFS, la más parecida a MinIO. Para un registro de imágenes que no dependa de Docker Hub, tienes el laboratorio del registro Docker privado y autoalojado.

Preguntas frecuentes

No. La API de Docker Hub responde 404 a minio/minio y a minio/mc: los repositorios se borraron. Docker sugiere docker login porque usa el mismo mensaje para un repositorio privado y para uno inexistente. La salida es cambiar la línea image: del compose.

¿Por qué MinIO se para con file access denied al usar la imagen de Chainguard?

Porque esa imagen corre como el usuario 65532 y tu directorio de datos pertenece a root, como lo dejaba la imagen oficial. Para el servicio, ejecuta chown -R 65532:65532 sobre los datos desde un contenedor desechable y vuelve a levantarlo.

¿Qué imagen uso para el cliente mc ahora que minio/mc no existe?

cgr.dev/chainguard/minio-client:latest, cuyo punto de entrada ya es mc. Corre como 65532, así que monta MC_CONFIG_DIR en una carpeta propiedad de ese usuario o mc alias set fallará con permission denied.

¿Puedo compilar MinIO desde el código fuente en lugar de usar Chainguard?

Sí. La guía original incluye un Dockerfile de 22 líneas que compila MinIO RELEASE.2025-10-15T17-29-55Z y mc en una imagen Alpine. No lo grabamos en este laboratorio porque la compilación tarda varios minutos; los parches pasan a ser cosa tuya.

Chuleta

```
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

¿Te ha servido? No te pierdas el próximo lab

Suscríbete a la newsletter

Qué demuestra la captura

Por qué la imagen de Chainguard necesita un chown

Dificultades con las que me he topado

Otras salidas que no grabamos

Preguntas frecuentes

¿Se arregla el error pull access denied de MinIO con docker login?

¿Por qué MinIO se para con file access denied al usar la imagen de Chainguard?

¿Qué imagen uso para el cliente mc ahora que minio/mc no existe?

¿Puedo compilar MinIO desde el código fuente en lugar de usar Chainguard?

Chuleta