nginx-proxy-manager: Unable to start npm container...

Dear all,

I’ve spent hours trying to get the following stack working but still encounter the following poor log file:

Checklist

  • Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
    • Yes
  • Are you sure you’re not using someone else’s docker image?
    • No
  • Have you searched for similar issues (both open and closed)?
    • Yes

Describe the bug Stack init seems to get stuck…

Nginx Proxy Manager Version Not able to get the stack accessible.

To Reproduce Steps to reproduce the behavior:

Docker-compose file:

version: '3'
services:      
  nginx-proxy-manager:
    container_name: nginx-proxy-manager
    restart: always
    image: jc21/nginx-proxy-manager:latest
    ports:
      - "81:81"
      - "80:80"
      - "4000:443"
    volumes:
      - "/mnt/docker/npm/data:/data"
      - "/mnt/docker/npm/letsencrypt:/etc/letsencrypt"
    environment:
      - DB_MYSQL_HOST=nginx-proxy-manager-db
      - DB_MYSQL_PORT=3306
      - DB_MYSQL_USER=XXX
      - DB_MYSQL_PASSWORD=XXX
      - DB_MYSQL_NAME=npm

    networks:
      - proxy_network
      - npm_network
  
  nginx-proxy-manager-db:
    container_name: nginx-proxy-manager-db
    image: jc21/mariadb-aria:10.4.15-innodb
    restart: always
    environment:
      - MYSQL_DATABASE=npm
      - MYSQL_USER=npm
      - MYSQL_PASSWORD=mysqlpass
      - MYSQL_ROOT_PASSWORD=mysqlrootpass
    volumes:
      - "/mnt/docker/npm/mysql:/var/lib/mysql"
    networks:
      - npm_network
    
      
networks:
  npm_network:
    driver: bridge
  proxy_network:
    external: true 

** Portainer log file **

❯ Configuring npm user ...
❯ Configuring npm group ...
❯ Checking paths ...
❯ Setting ownership ...

Operating System Debian 10

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 18 (4 by maintainers)

Commits related to this issue

Most upvoted comments

Before this happen to me, I try to backup NPM instance. It is absurdly long time to copy. I inspect it and found that certbot generate more than 100,000 file for each letsencrypt/csr and letsencrypt/key.

The “Setting ownership …” is a part of script to chmod all files related. I guess that’s where the problems came from.

My change was included, but then inadvertently broken again.

https://github.com/NginxProxyManager/nginx-proxy-manager/blob/209c1b33347d1ea82870e742edf5039cc254d7ba/docker/rootfs/etc/s6-overlay/s6-rc.d/prepare/30-ownership.sh#L28

The -R is not needed. The existing sub directories/files don’t need their permissions changed. Only the site-packages directory needs to be write-able by the user.

The existing ones are part of the root install that is readable by all.

yes, in the morning all is good. Even if I restart it, it starts up quickly. So I guess it was only trying to do some maintenance or something.