I spent a night debugging what looked like a single broken Docker container on my ASUS ROG Zephyrus S GX531GM (i7-8750H, GTX 1060 6GB, Linux Mint). It turned out to be three separate, unrelated bugs stacked on top of each other. Here’s the full trail, in case it saves someone else the same night.
The Setup
The goal was simple: get Open WebUI v0.10.2 running in Docker on the laptop, talking to a local Ollama instance, so I’d have the same self-hosted AI chat interface on the go that I already run at home.
Docker was installed. Ollama was installed with CUDA support and had a model pulled (llama3.2:3b-instruct-q6_K). Should have been a five-minute docker run.
Bug #1: “Waiting for Application Startup” Forever
First attempt:
docker run -d \
-p 3000:3000 \
--add-host=host.docker.internal:host-gateway \
-e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
-e WEBUI_AUTH=False \
-v open-webui:/app/backend/data \
--name open-webui \
--restart always \
ghcr.io/open-webui/open-webui:v0.10.2
The container reported healthy. Port 3000 was listening. But the browser just hung, and docker logs showed the app stuck at “Waiting for application startup” indefinitely.
I tried the usual suspects: HF_HUB_OFFLINE=1 to stop it from reaching out to Hugging Face, toggling WEBUI_AUTH, disabling UFW entirely for testing. Nothing changed.
The real fix was patience, not configuration. Watching docker logs -f live (instead of checking after the fact) showed the container was actually downloading an embedding model (all-MiniLM-L6-v2, ~30 files) from Hugging Face on first boot — something v0.10.2 needs for its RAG/memory features. It just took a couple of minutes and produced no obvious “downloading, please wait” signal in the truncated log view I’d been checking. Once that finished, the app moved past startup and the scheduler came online.
Lesson: before assuming a hang, tail the entire live log, not a snapshot.
Bug #2: The Port That Wasn’t Listening
With startup apparently complete, the browser still couldn’t connect — now failing outright with “connection reset” instead of just hanging.
curl -v http://localhost:3000
...
* Recv failure: Connection reset by peer
TCP was connecting fine (Docker’s port-forwarding proxy accepted the connection), but something on the other end was immediately resetting it. That’s a very different signal from a timeout — it meant nothing was listening on the port I was forwarding to.
The check that cracked it:
docker top open-webui
CMD
/usr/local/bin/python3 -m uvicorn open_webui.main:app --host 0.0.0.0 --port 8080 ...
The app inside the container was listening on port 8080, not 3000. My docker run command had -p 3000:3000 — forwarding host port 3000 to a container port where nothing was running. A leftover assumption from an older setup guide, never actually verified against this version.
Fix: recreate the container with the correct mapping.
docker run -d \
-p 3000:8080 \
--add-host=host.docker.internal:host-gateway \
-e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
-e WEBUI_AUTH=False \
-v open-webui:/app/backend/data \
--name open-webui \
--restart always \
ghcr.io/open-webui/open-webui:v0.10.2
curl http://localhost:3000 immediately returned a real HTTP 200 with the actual page HTML. First real win of the night.
Bug #3: Ollama Was Only Listening to Itself
The web UI loaded. The account setup screen worked. But the Models page showed zero models — despite Ollama running fine and curl http://localhost:11434/api/tags on the host returning the model correctly.
The difference: that curl was running on the host. Open WebUI runs inside a container, reaching Ollama over Docker’s internal bridge network, not localhost. Testing from inside the container told a different story:
docker exec -it open-webui curl -v http://host.docker.internal:11434/api/tags
* Trying 172.17.0.1:11434...
* connect to 172.17.0.1 port 11434 failed: Connection timed out
Checking systemctl status ollama explained why — every single logged request in Ollama’s history came from 127.0.0.1. Ollama was bound to localhost only, silently ignoring anything arriving from the Docker bridge IP.
Fix: a systemd override forcing Ollama to listen on all interfaces.
sudo systemctl edit ollama
[Service]
Environment="OLLAMA_HOST=0.0.0.0"
sudo systemctl daemon-reload
sudo systemctl restart ollama
Bug #3.5: UFW Was Still in the Way
Even with Ollama listening everywhere, the container still couldn’t connect — because UFW, which I’d re-enabled after initial testing, had no rule allowing traffic from the Docker bridge subnet at all. Ollama was open; the firewall wasn’t.
sudo ufw allow from 172.17.0.0/16 to any port 11434
That was the last piece. docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags finally returned the real model list, and the model appeared in the Open WebUI dropdown a moment later.
Bonus: Making It Actually Fast
With everything connected, I also tuned Ollama’s systemd service for better performance on the laptop’s GTX 1060:
[Service]
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Flash attention computes the same attention math more memory-efficiently — no quality tradeoff, just a smarter implementation. Q8_0 KV cache quantization roughly halves the VRAM cost of longer conversations for an essentially unmeasurable quality cost (published benchmarks put the perplexity difference in the range of 0.002–0.05). Together, they buy meaningfully more headroom on a 6GB card without giving anything up.
Verified with a live inference test on two different models afterward — both responded normally, no crashes, no silent fallback behavior.
The Actual Lesson
None of these three bugs were exotic. A wrong port mapping. A service bound to the wrong interface. A firewall rule that didn’t exist yet. Individually, each one is a five-minute fix once you’ve identified it. Stacked on top of each other, each one perfectly disguised the next — the port bug looked like a startup hang, the Ollama bind issue looked like the port bug’s cousin, and the firewall issue looked like the bind fix hadn’t worked at all.
The tool that actually cracked each layer wasn’t a config change — it was docker top, curl -v, and systemctl status, checked one at a time, each one ruling out exactly one possibility before moving to the next. Slower than guessing, but it’s the only way three unrelated bugs get found instead of one getting “fixed” by accident while the other two linger.
Running Open WebUI + Ollama on a Linux laptop, ASUS ROG Zephyrus S GX531GM, Linux Mint 22.3.