Access to MinIO issue

[samg666]

Hello,

I am trying to access MinIO and followed below guide https://docs.budibase.com/docs/accessing-minio, turned docker-compose.yaml MINIO_BROWSER: "on", then restarted docker and server, but still not able access via URL your-budibase-host/minio.

My budibase URL http://192.168.100.14:10000/, tried access via http://192.168.100.14:10000/minio or http://192.168.100.14:9000/ or http://192.168.100.14:9000/minio, all not work. Could someone give some help?

BTW, the reason why I want to access MinIO is I am going to migrate my Budibase, then I am thinkg to backup the uploaded files and move to my new Budibase manually. Is this a right way, or any other suggestion?

[melohagan]

Try updating the minio-service section of the docker-compose.yaml with the following:

ports:
      - "9000:9000"
      - "9001:9001"

command: server --console-address ":9001" /data

Let me know if that resolves your issue!

[samg666]

Hi @melohagan , thanks for you reply. I have recently upgrade Budibase, and found there's no ports config on the new docker-compose.yaml. I have turned on MINIO_BROWSER: "on", but still not able to access http://192.168.100.14:9000/ or http://192.168.100.14:10000/minio (my Budibase running on http://192.168.100.14:10000). If I access via http://192.168.100.14:10000/minio, then the browser being redirected to http://192.168.100.14:46577/.

Actually, the reason why I want to access MinIO is I am going to migrate my Budibase, and I have some uploaded files needs to be migrate as well. Is there any better way to migrate the upload files?

Below are the new docker-compose.yaml minio-service config

  minio-service:
    restart: unless-stopped
    image: minio/minio
    volumes:
      - minio_data:/data
    environment:
      MINIO_ACCESS_KEY: ${MINIO_ACCESS_KEY}
      MINIO_SECRET_KEY: ${MINIO_SECRET_KEY}
      MINIO_BROWSER: "on"
    command: server /data
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
      interval: 30s
      timeout: 20s
      retries: 3

[melohagan]

And you couldn't access your-budibase-host/minio even if you remove the ports section and revert the command to command: server /data

There may be some other port forwarding needed on the AWS side. There's a mention here: minio/minio#4793

[ssuryansh]

And you couldn't access your-budibase-host/minio even if you remove the ports section and revert the command to command: server /data

There may be some other port forwarding needed on the AWS side. There's a mention here: minio/minio#4793

@melohagan - I have removed the ports section and revert the command to command: server /data.It didn't work still. But i am able to access couchdb UI according to the budibase documentatoin but getting issue in accessing minio UI.and this is very critical for our application which we are designing.

[melohagan]

It does seem like it could be a port forwarding issue then. The user for that minio issue I linked was also hosting on AWS Ubuntu. Try having a look through it, and the linked StackOverflow port forwarding guide.
Sorry I couldn't be of more help!

[ssuryansh]

@melohagan- How can we run budibase source code on local server.
Actually we want to add some components locally in cloned source code of budibase and try to test those components locally before pushing to remote repository.

[levimk]

@ssuryansh - I was having the same issue. It looks like it has something to do with forwarding config. If I follow the docs and go to localhost:10000/minio then it redirects me to mini-service:9000 (the service name in the docker-compose). Instead of trying to access minio via localhost:10000/minio, I simply went to http://localhost:9001/ (the URL in the docker-compose). I was able to log into my local minio instance. I imagine this would be either an NGINX issue or a Docker networking issue.

[theDonM]

I had this issue 2 days ago (minio exiting with error 127) while running budibase using their default docker-compose.yaml. The issue for me was that I'm using repurposed ("upcycled" for the younger crowd) machines that have AMD G34 socket processors (Opteron 6128). Minio was throwing "Fatal glibc error: CPU does not support x86-64-v2" errors because the CPU does not support x86-64-v2. Replacing the Minio image from the yaml with the image from this page worked beautifully.

Explicitly:
minio-service:
image: quay.io/minio/minio:RELEASE.2023-11-01T01-57-10Z-cpuv1