open-webui will not run with Ollama systemd and host.docker.internal

[ganakee]

I am baffled. I had ollama-webui running fine. I updated to open-webui and no matter what I cannot get the webui to connect to the ollama instance.

I tried searching the drive but cannot find where open-webui stores the config data. No matter what I do, I cannot get webui to accept the URL for the ollama instance. It says SAVE but does not save.
No Matter what, the webui tries to use the default docker URL.

My config is Ollama. Verified Ollama running on all ports: 127.0.0.1 and 192.168.71.117. But the docker instance using --network=local or not, specifying the IP OLLAMA_HOST, etc. none allow connection with open-webui.
I am wondering if there might be something left over after the upgrade. I did a full upgrade removing the old ollama-webui.

Just baffled what else could be going on.

Ollama running on all ports 0.0.0.0:11434--verified.
Run openwebui from docker.
I see the open-webui web interface at (for me 3030 but even on default 8080 same). I login but nothing else takes and the open-webui does not see the Ollama instance. I tried all the suggestions for troubleshooting multiple times.

[justinh-rahb]

Use OLLAMA_BASE_URL=http://host.docker.internal:11434

Previously it was OLLAMA_API_BASE_URL=http://host.docker.internal:11434/api

Note how it has been changed: the variable name no longer has API_ and the value expected should not have /api on the end.

[ganakee]

Thank you @justinh-rahb . However, this still does not work.
I have tried a number of permutations.
Between each trial

docker stop open-webui
docker rm open-webui

Tried again:

docker run -d -p 3030:8080 -e OLLAMA_BASE_URL=http://host.docker.internal:11434 --network=host -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

docker run -d -p 3030:8080 -e OLLAMA_BASE_URL=http://host.docker.internal:11434 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

docker run -d -p 3030:8080 -e OLLAMA_BASE_URL=http://host.docker.internal:11434 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

There is no question that Ollama runs on 127.0.0.1:11434 and a local IP 192.168.71.171:11434.
Yet, the webui simply does not see or connect. (My old ollama-webui was fine.) I cannot get to the host.docker.internal.

traceroute host.docker.internal
host.docker.internal: Name or service not known
Cannot handle "host" cmdline arg `host.docker.internal' on position 1 (argc 1)

ping host.docker.internal
ping: host.docker.internal: Name or service not known

I even tried 172.17.0.1 because this is bound to the docker:

docker run -d -p 3030:8080 -e OLLAMA_BASE_URL=http://172.17.0.1 --network=host -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

docker run -d -p 3030:8080 -e OLLAMA_BASE_URL=http://172.17.0.1:11434 --network=host -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

The result is now:
Server connection failed and no connection is possible.
HOWEVER, this is a little different error as the open-webui DOES show the 172.17.0.1 address. You just cannot connect. You also cannot save or correct the IP in the open-webui.

Hmm.....

[justinh-rahb]

How did you install Docker?

[ganakee]

I believe via apt.

[justinh-rahb]

Unless you also added Docker's repo to your sources then it's likely you're using an older version.

[ganakee]

Thanks @justinh-rahb .

I got it. I tried:
docker run -d -p 3030:8080 -e OLLAMA_BASE_URL=http://172.17.0.1:11434 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
This removes the --network=local from the before examples. It uses the docker IP 172.17.0.1 rather than the problematical-for-me host.docker.internal.

So, I am not sure why this works.

If this helps others:

My config is Ollama running on a local IP range 192.168.xxx.xxx. I run via systemd.

/etc/systemd/system$ cat ollama.service
[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama.gpu serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"
Environment="OLLAMA_MODELS=/home/me/somewhere/models" 
Environment="PATH=/home/me/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"

[Install]
WantedBy=default.target

I updated from ollama-webui to open-webui using the instructions at:
https://docs.openwebui.com/migration

Then I removed the old open-webui attempts installed via

docker stop open-webui
docker rm open-webui

Then I used:
docker run -d -p 3030:8080 -e OLLAMA_BASE_URL=http://172.17.0.1:11434 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Note: I map the docker open-webui 8080 port to 3030 for my internal needs. So, openwebui is available in my network at https://192.168.xx.xxx:3030/. Not everyone may need the -p 3030:8080 mapping.

[justinh-rahb]

Given that host.docker.internal is not working, I think it highly likely that you're using a distro's package from their repo and not Docker's. Distro versions tend to be outdated and may not support the host gateway alias.

[ganakee]

I really appreciated your help @justinh-rahb . The outdated repo issue sounds reasonable, but I just checked. I use the repo version. . https://download.docker.com/linux/ubuntu

docker --version
Docker version 26.1.2, build 211e74b

The install is by the repo method at https://docs.docker.com/engine/install/ubuntu/#install-from-a-package

I also checked history and see that this is the method that I used.

[justinh-rahb]

Dunno how I missed it earlier but your docker run commands have been missing the --add-host=host.docker.internal:host-gateway argument. This should be before the image name, but after docker run -d

[ganakee]

Not a problem. I will try that (and it answers a question I pondered how docker knows about this mapping). Thank you.