whenever I try to run a podman container, it’ll through:
Error: running container create option: container has joined pod 4f[long_string]b1f and dependency container 34[long_string]9cd is not a member of the pod: invalid argument
An example of a dependent container compose file looks like this:
services:
# https://docs.linuxserver.io/images/docker-qbittorrent
qbittorrent:
image: lscr.io/linuxserver/qbittorrent:latest
container_name: qbittorrent
environment:
- WEBUI_PORT=8090
- PUID=0
- PGID=0
volumes:
- ./config:/config:Z
- ./files:/media:z
restart: always
depends_on:
- gluetun
network_mode: "container:gluetun"
services:
# https://github.com/qdm12/gluetun
gluetun:
image: docker.io/qmcgaw/gluetun
container_name: gluetun
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
ports:
- 8001:8000 # gluetun
- 8090:8090 # qbittorrent
volumes:
- ./config:/gluetun:Z
environment:
- KEYS=REDACTED
restart: always
privileged: true
It worked until yesterday. I updated to fedora 40. I am not sure if that is just a coincidence or if that’s the reason. Should I downgrade to 39?
Generally to depend on a container it needs to be in the same compose project, so if you move gluetun into the one with qbittorrent it should work fine.
I’ve been running that since many months like that. Why did that break now …
It works in the same file. I don’t want to have 10 containers in the same compose file.
I checked, it works in the same file, thx.
Removing “depends: gluetun” does not work either
But that’s like the whole point of docker compose. If you are just going to have 1 container per file what benefit are you even getting out of using a compose file?
Docker compose is just a setting file for a container. It’s the same advantage you get using an ssh config file instead of typing out and specifying a user, IP, port, and private key to use each time. What’s the advantage to putting all my containers into one compose file? It’s not like I’m running docker commands from the terminal manually to start and stop them unless something goes wrong, I let systemd handle that. And I’d much rather the systemd be able to individually start, stop, and monitor individual containers rather than have to bring them all down if one fails.
deleted by creator