Can't access docker-compose services on their ports

I have been using Portainer, off and on, for not too long (less than 6 months). I’m getting a docker-based media server going (based mostly on https://www.smarthomebeginner.com/traefik-2-docker-tutorial/ just without messing with traefik).

So, a while back, I learned about being able to put docker-compose scripts in “stacks” and deploy them (after customizing them with my setup). I’ve got plex, nzbget, duckdns, etc running. About 17 or so so far. But after a point, I couldn’t access the config pages of the images. I just get an nginx 404 page. I’ve tried deploying the image(s) through stacks, or by just entering config info into “new container.” But, when I enter on the command line “docker run -p 85:80 repository/image” they work fine. I get the config page and everything.

Do I have too many containers or stacks? Is there a certain limit I need to increase in Portainer? Like I’ve said, I’ve tried as containers or as stacks. I’ve also tried messing around with port mappings, and switching from bridge network to host. An example that won’t work for me is linuxserver/organizr. I’ve also tried lsiocommunity/organizr. I also couldn’t get muximux to work. They all work through the commandline with docker run, though. That’s why I’m thinking I hit a limit. But I don’t want to run some things outside of portainer.

Host machine:
Debian 10.4
I5 9400
16 GB RAM
900 tb SDD for / only 1% used, only using 3.5 GB of 15.5 GB

Portainer is actually running as an image itself. portainer/portainer:latest (1.24.0)

Any ideas?

Wackman

There should be no issue with resource usage. Docker-compose networking is different to a simple docker run so I would try accessing the services on the host IP in the browser rather than localhost if you’re not already.

Also make sure you are publishing your ports in the docker compose file

Thanks for the response. Here’s what I’m currently using as a docker compose section (in stacks):

organizr:
container_name: organizr2
restart: always
image: lsiocommunity/organizr
volumes:
- /home/wackman/docker/config:/config
- /home/wackman/docker/shared:/shared
ports:
- “85:80”
environment:
- PUID=1000
- PGID=998
- TZ=America/Los_Angeles

I just tested it, since it’s been 24 hours and I’m still getting an nginx 404 error. So enough of the image is running to give me an nginx response, but something else is going on. I called it Organizr2 since the previous attempt was just a straight container configuration with the same information. Rather than deleting and recreating, I just renamed so they didn’t conflict.

Oh, one more thing. I’ve tried accessing it as http : //hostname:85, http://192.168.1.250:85 and http://172.17.0.17:85 (shouldn’t work, but I was grasping at straws). I’ve tried doing a dmesg inside the container to see if there were any system errors internally, but no permissions to do it. No /var/log/messages in the container to check out either. The docker logs don’t show any errors either.

Try that compose file via docker-compose up on the CLI and see if it has the same behavior. Sounds like organizr uses nginx and that the issue is something to do with how nginx is configured. You may need to play around with this config. Maybe this will help you

itsconquest-staff,

Thankyou again for your help. I think I got it solved. I think it’s due to outdated image(s). Organizr is on the cusp of releasing version 2 and the images I was pulling were based on v1.

I created a test docker-compose.yml with the same thing from my stack, but it gave the same nginx 404 error. That told me that it wasn’t a portainer issue, but probably a problem with the images. In fact, their github page says a release from Feb 2019 was probably going to be it for v1. It’s likely all the v1 images were broken. Regardless, I updated to a v2 image and it worked, both outside and inside portainer.

So, now I’m running Organizr v2 as a stack. I could have sworn there was one or two other things that gave me the same problem, but everything seems good for now. From now on, my first step will be to see if there is anything more updated floating around out there.

Wackman

Glad to hear this could be resolved!