Minio permission denied

Question

When I start my docker container, I have a problem with minio this is my error:

19:32:16.16 INFO ==> ** Starting MinIO setup **

/opt/bitnami/scripts/libminio.sh: line 324: /data/.root_user: Permission denied

On windows it works but on linux not

this is my docker-compose settings:

        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:
            - ./docker-volumes/s3-data:/data
        networks:
            - proxy

Answer 1

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 ).