Komga container is running, but its web interface is unreachable on port 25600
Asked by
MellowCedar47
I'm trying to deploy Komga in a Docker container on Catchy OS. The container starts, but I can't open the web interface at localhost:25600. I also tried the host computer's LAN address and its Tailscale address, with the same result. Three other containers—Audiobookshelf, Immich, and Navidrome—are working normally.
So far I've rebuilt the Compose file, opened the relevant firewall ports, checked folder ownership, and reviewed the logs without finding an obvious error. The Compose configuration is:
services:
komga:
image: gotson/komga
container_name: komga
volumes:
- type: bind
source: /home/$me/containers/Komga/config/
target: /config
- type: bind
source: /home/$me/containers/Komga/data/
target: /data
- type: bind
source: /home/$me/Documents/comics/
target: /comics
ports:
- 25600:25600
user: "1000:1000"
environment:
- TZ=America/Los_Angeles
restart: unless-stopped
What should I check to determine whether this is a Docker port issue, a Komga startup problem, a bind-mount permission problem, or something on the host network?
Answers
Since you’re testing from the same computer, localhost is appropriate if the service is published correctly; a firewall is not required for that local test. If localhost, the machine’s LAN IP, and the Tailscale IP all fail, that points more toward Komga not listening or the container not being published correctly than toward a remote routing issue. The most useful next information would be the output of `docker compose ps`, `docker port komga`, the local curl result, and the first relevant startup error from the logs.
Reply to this answer
Also check whether another process already owns port 25600. `docker compose ps` and `docker port komga` will show whether Docker actually published it, while `ss -ltnp | grep 25600` can show what is listening on the host. If the port is already occupied, change the host side of the mapping, for example `25601:25600`, and connect to port 25601.
Reply to this answer
The forced `user: "1000:1000"` is worth investigating. That UID and GID need read/write access to the config and data directories, as well as access to the comics directory. Compare `id` with the ownership and permissions from `ls -ld` on all three paths. Also run `docker compose config` to verify that `$me` expands to the path you expect and that you’re launching Compose as the correct user. Avoid using broad permissions such as `chmod 777` as a first fix.
Reply to this answer
The port mapping looks right, so I’d test each layer instead of repeatedly changing the Compose file. First run `docker compose ps` and `docker port komga`; you should see port 25600 published on the host. Then test locally with `curl -v http://127.0.0.1:25600/` and inspect `docker logs --tail=200 komga`.
If curl fails on the Docker host, Komga may not have finished starting or may be unable to write to one of the mounted directories. If curl works locally but remote devices cannot connect, focus on the host firewall and make sure you’re connecting to the Docker host’s actual LAN or Tailscale address rather than using localhost.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowCedar47: I was testing locally first, which is why I used localhost. I also tried the computer’s LAN address and its Tailscale address, but neither worked.