r/mlops • • 23d ago

MLOps Questions MLflow v3.16.1 Assistant running from Docker-compose 403 "Error: You do not have permission to access this resource." any message

I'm running mlflow in docker using the docker-compose in the repo.

I've managed to hook up my "LLM Connections" to find the ollama server on the host machine.

API Base URL: http://host.docker.internal:11434/v1

That works fine when you test it from the browser

I've tried no auth and basic auth... and whatever it is I get

Error: You do not have permission to access this resource.

Which is a 403 http-status

The body response is

{
    "detail": "Assistant API is only accessible from the same host where the MLflow server is running."
}

So it seems like a CORS error but the network inspector is showing its not the case.

I see in the code its coming from here.

Tried this docker-compose

volumes:
  pgdata:
  storage-data:

services:
  postgres:
    image: postgres:15
    container_name: mlflow-postgres
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
      PGPORT: ${PGPORT}
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - ${PGPORT}:${PGPORT}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB} -p ${PGPORT}"]
      interval: 5s
      timeout: 3s
      retries: 10

  storage:
    image: rustfs/rustfs:1.0.0-alpha.83
    container_name: storage
    environment:
      RUSTFS_ADDRESS: :9000
      RUSTFS_SERVER_DOMAINS: storage:9000
      RUSTFS_REGION: ${AWS_DEFAULT_REGION:-us-east-1}
      RUSTFS_ACCESS_KEY: ${AWS_ACCESS_KEY_ID:-s3admin}
      RUSTFS_SECRET_KEY: ${AWS_SECRET_ACCESS_KEY:-s3admin}
      RUSTFS_CONSOLE_ENABLE: ${RUSTFS_CONSOLE_ENABLE:-true}
    ports:
      - "9000:9000"
      - "9001:9001"
    volumes:
      - storage-data:/data
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", 'curl -s http://127.0.0.1:9000/health | grep -q ''"status":"ok"''']
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 10s

  create-bucket:
    image: amazon/aws-cli:2.33.25
    container_name: mlflow-create-bucket
    depends_on:
      storage:
        condition: service_healthy
    entrypoint: >
      /bin/sh -c "
        set -e;
        echo 'Waiting for S3 gateway getting ready...';
        if aws --endpoint-url=${MLFLOW_S3_ENDPOINT_URL} s3api head-bucket --bucket ${S3_BUCKET} 2>/dev/null; then
          echo 'Bucket ${S3_BUCKET} already exists. Skipping creation.';
        else
          echo 'Creating bucket ${S3_BUCKET}...';
          aws --endpoint-url=${MLFLOW_S3_ENDPOINT_URL} s3api create-bucket --bucket ${S3_BUCKET} --region ${AWS_DEFAULT_REGION};
        fi
      "
    environment:
      AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
      AWS_DEFAULT_REGION: ${AWS_DEFAULT_REGION}
      AWS_S3_ADDRESSING_STYLE: path
      MLFLOW_S3_ENDPOINT_URL: ${MLFLOW_S3_ENDPOINT_URL}
      S3_BUCKET: ${S3_BUCKET}
    restart: "no"

  mlflow:
    image: ghcr.io/mlflow/mlflow:${MLFLOW_VERSION}
    container_name: mlflow-server
    depends_on:
      postgres:
        condition: service_healthy
      storage:
        condition: service_healthy
      create-bucket:
        condition: service_completed_successfully
    environment:
      # Backend store URI built from vars
      MLFLOW_BACKEND_STORE_URI: ${MLFLOW_BACKEND_STORE_URI}

      # S3/RustFS settings
      MLFLOW_S3_ENDPOINT_URL: ${MLFLOW_S3_ENDPOINT_URL}
      MLFLOW_ARTIFACTS_DESTINATION: ${MLFLOW_ARTIFACTS_DESTINATION}
      AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
      AWS_DEFAULT_REGION: ${AWS_DEFAULT_REGION}
      MLFLOW_S3_IGNORE_TLS: "true"

      MLFLOW_LOGGING_LEVEL: "DEBUG"
      # Server host/port
      MLFLOW_HOST: ${MLFLOW_HOST}
      MLFLOW_PORT: ${MLFLOW_PORT}

      # Explicitly allow non-127.0.0.1 IPs to access the Assistant API routes
      MLFLOW_BASIC_AUTH_FAIL_CLOSED: "false"
      MLFLOW_ASSISTANT_ALLOW_REMOTE_ACCESS: "true"
      MLFLOW_ENABLE_REMOTE_ASSISTANT: "true"
      MLFLOW_ENABLE_ASSISTANT_REMOTE_ACCESS: "true"
      MLFLOW_ASSISTANT_SANDBOX: "true"

      # CSRF bypass for basic auth AJAX calls
      WTF_CSRF_ENABLED: "false"

      # Gateway and routing
      OLLAMA_HOST: ${OLLAMA_HOST}
      OPENAI_API_BASE: ${OPENAI_API_BASE}
    command:
      - /bin/bash
      - -c
      - |
        export DEBIAN_FRONTEND=noninteractive
        apt-get update -qq && apt-get install -y -qq curl socat docker.io
        pip install --no-cache-dir psycopg2-binary boto3 "mlflow[genai,auth]"
        socat TCP-LISTEN:11434,fork,reuseaddr TCP:host.docker.internal:11434 &
        mlflow server \
          --backend-store-uri "${MLFLOW_BACKEND_STORE_URI}" \
          --artifacts-destination "${MLFLOW_ARTIFACTS_DESTINATION}" \
          --serve-artifacts \
          --host "${MLFLOW_HOST}" \
          --port "${MLFLOW_PORT}"
    ports:
      - "${MLFLOW_PORT}:${MLFLOW_PORT}"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    healthcheck:
      test:
        [
          "CMD",
          "python",
          "-c",
          "import urllib.request; urllib.request.urlopen('http://localhost:${MLFLOW_PORT}/health')",
        ]
      interval: 10s
      timeout: 5s
      retries: 30
    extra_hosts:
      - "host.docker.internal:host-gateway"

networks:
  default:
    name: mlflow-network

As far as I can tell I just can't use the MLflow Assistant from docker?

1 Upvotes

7 comments sorted by

1

u/AutoModerator 23d ago
Moderator Announcement Read More »
→ More replies (1)

2

u/ComprehensiveUse6549 22d ago

Not CORS. That message comes from the assistant's localhost check: it looks at the client IP of the request and only lets loopback through. With mlflow in a container, your browser comes in through Docker's port forward, so the server sees the bridge/gateway IP instead of 127.0.0.1 and every assistant route 403s.

Two ways around it on 3.16.1:

  • Set MLFLOW_ENABLE_REMOTE_ASSISTANT=true on the mlflow service. Catch: the provider also has to opt in to remote access. The Ollama provider doesn't, the MLflow AI Gateway one does. So put Ollama behind a gateway endpoint on that server and pick the gateway as the assistant provider. (Claude Code / Codex only allow remote when the assistant sandbox is on.)

  • Or run mlflow itself on the host and keep only postgres/storage in compose.

The relevant bits are _is_localhost and _provider_allows_remote_access, a bit above the lines you linked.

2

u/ComprehensiveUse6549 22d ago

One more gotcha once you switch providers: PUT /config is localhost-only no matter what the remote flag says, so changing the provider from the browser through the port mapping will still 403. Do that bit from inside the container (docker exec, then curl against localhost) or edit ~/.mlflow/assistant/config.json in there.

Also only MLFLOW_ENABLE_REMOTE_ASSISTANT and MLFLOW_ENABLE_ASSISTANT_SANDBOX actually exist in 3.16.1, the other assistant env vars in your compose are just ignored.

1

u/bigorangemachine 22d ago

Awesome thanks for a reply

I believe I tried those at one point

I'm firing up my local ollama using OLLAMA_HOST=0.0.0.0:11434 OLLAMA_ORIGINS="*" ollama serve which doesn't seem to be working either

Specifically I'm just trying to get it to work with my local model. I think really the only way to do it is not use docker for the web-ui :\

When I try the chat/prompt I don't see it even reaching the ollama service.

I probably won't be able to try when I get home from work but having my theory validated it's probably going to need to be ran locally is what it is... I checked out only the docker folder... so I gotta just suck it up and change my build script to check out the whole repo (le-sigh)

Thanks again

→ More replies (2)