Minio permission denied – Docker

The problem

You are bind-mounting the directory ./docker-volumes/s3-data into the container. Initially this directory doesn’t exist, so Docker creates it — as root. This means that the /data directory inside the container is owned by root.

Unfortunately, inside the container minio is running as user 1001, so it doesn’t have sufficient permissions to create files (or directories) inside /data.

Solution 1: Docker volumes

If instead of bind-mounting a host directory you use a named docker volume, like this:

version: "3"

services:
  minio:
    container_name: minio
    image: "bitnami/minio:latest"
    ports:
        - "9000:9000"
        - "9001:9001"
    environment:
        - MINIO_ACCESS_KEY=${ACCESS_KEY}
        - MINIO_SECRET_KEY=${SECRET_KEY}
        - MINIO_DEFAULT_BUCKETS=${BUCKET}
    volumes:
        - minio_data:/data

volumes:
  minio_data:

Then Docker will set the owner and permissions of the volume to the permissions of the directory on which you are mounting the volume. In the bitnami/minio image, /data looks like:

[lars@docker work]$ docker run -it --rm  bitnami/minio:latest ls -ld /data
[...]
drwxrwxr-x. 2 root root 6 May 22 00:55 /data

That is, it’s writable by user root and group root. The minio container is running as UID 1001 and group root, so it’s able to write to that directory.

Solution 2: Futzing with permissions

You can, of course, explicitly pre-create the docker-volumes/s3-data
directory and then chown it to the appropriate userid:

sudo chown 1001 docker-volumes/s3-data

But in general, unless there’s a reason why you need to use a specific
host directory, using a named Docker volume as in solution 1 is going
to be more manageable (because you don’t need to know the container
userid in advance, and because you won’t end up with files owned by
non-you userids in your home directory ).