Open otavio-silva opened 5 months ago
I am not sure if my issue is the same, but I have updated podman from 4.9.3 to 5.0.1 two days ago, and since then it looks like my host services cannot be accessed from within the container context.
In the picture you can see my grafana dashboard monitoring my development API. RabbitMQ runs in a container, the oracle DB and the main API service run on the host. The gap is where I performed the update.
The oracledb prometheus exporter keeps spamming
2024-04-05T07:55:29+02:00 time="2024-04-05T05:55:29Z" level=error msg="Error pinging oracle: ORA-12541: TNS:no listener\n" source="main.go:215"
as it cannot reach the host at host.docker.internal
or host.containers.internal
.
As a workaround I looked into the compose spec and tried different things like a host network, but those aren't supported by podman (yet?)
As a sanity check I have reinstalled the older version of podman (4.9.3), with the following results:
So for the time being I will pin/hold my package at that version, but I hope this can be resolved in 5.0.2 or some other version soon. I could look into fixing this myself, but I have very little experience in Go, VMs, or networking...
Excerpt of my docker-compose file:
clipboard-oracledb-exporter:
image: iamseth/oracledb_exporter
networks:
- clipboard_api_default
environment:
DATA_SOURCE_NAME: oracle://username:password@host.docker.internal:1521/XE
ports:
- "9161:9161"
I found a similar issue when upgrading from Fedora Silverblue 39 (Podman 4.9.4) to 40 (podman 5.0.1). In FS39 I can reach host ports inside a container attached to a network defined in docker-compose.yml file. In FS40, the connection is refused. Toolbox created containers can connect to host on both FS39 and FS40.
I tried reseting and recreating again with podman system reset
in FS40, but it didn't work.
I rebased again to FS39 (I didn't pin before rebasing to FS40 :disappointed: ) and it works again.
PS: I'm using podman-remote inside a toolbox to create the containers in the host, maybe it could be related...
I am not sure about Windows, but on Linux, I have this problem from Podman 5 (after upgrading to Fedora 40). Just like @maxtorete
The problem is probably related to the Pasta network driver, which has been default since v5.
When I switched from pasta back to slirp4netns, it worked again.
$ cat ~/.config/containers/containers.conf
[containers]
[engine]
[machine]
[network]
default_rootless_network_cmd="slirp4netns"
[secrets]
[configmaps]
@dontfreakout Cheers for this tip! This got my Cloudflare SSH-tunnel working again.
However, I need to read Pasta docs to see how host access should really be done with it.
@kontza can you share the steps you did to make this change...I must be doing it wrong as still not working for me.
@kontza can you share the steps you did to make this change...I must be doing it wrong as still not working for me.
Short story: I started to use host networking.
For the record, and I think it's important: using the Ollama app instead of just using the command line, a UAC prompt asked me to enable access for ollama.exe
to networking.
After giving permission, using podman run -d -p 11435:8080 -e OLLAMA_BASE_URL=WIN_IP:11434 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
worked just fine.
Issue Description
I'm trying to run the Open WebUI container and access the Ollama API exposed on
http://localhost:11434
, since Ollama is installed on my local Windows 11 machine. However, the container running in the Podman machine (podman-machine-default
WSL2 distro) cannot reach addresses on the Windows host.Steps to reproduce the issue
Steps to reproduce the issue
WIN_IP
is the result ofip route show | grep -i default | awk '{ print $3}'
onpodman-machine-default
: 1.podman run -d -p 11435:8080 --add-host=host.containers.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
2.podman run -d -p 11435:8080 -e OLLAMA_BASE_URL=WIN_IP:11434 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
3.podman -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://WIN_IP:11434 --name open-webui --restart always ghcr.io/open-webui/open-webui:main
http://localhost:11435
orhttp://localhost:8080
if using the--network=host
flagpodman logs
shows theERROR:apps.ollama.main:Connection error: Cannot connect to host WIN_IP:11434 ssl:default [Connection refused]
Describe the results you received
The container could not reach the Windows app in any way
Describe the results you expected
The container to retrieve results from the address on the Windows host
podman info output
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
Yes
Additional environment details
The command
wsl --version
gives:Additional information
I've used the issues #14933, #13966 and #13965 as references but none of them could actually fix the issue