Nginx-proxy-manager: jc21/mariadb-aria:10.4 database fails on ARM architecture (workaround)

[MaxVRAM]

Summary

Using the latest setup instructions on the NPM website, the jc21/mariadb-aria:10.4 image fails on Raspberry Pi OS (EDIT: just realised this was with a Pi running Ubuntu Server, regardless, ARM architecture) (5.4.0-1013-raspi) with a exec user process caused "exec format error" in the Docker log.

To reproduce

1. Have a Raspberry Pi using Raspberry Pi OS Ubuntu Server (5.4.0-1013-raspi) or potentially any distro.
2. Create a docker-compose.yml and config.json using the setup guide on the npm website.
3. Deploy using docker-compose up -d.

Result

The stack doesn't load correctly, with errors showing in both the database and app services. Critically, the database service does not allow docker exec -it <container> bash entry, stating that it is currently restarting, and displaying exec user process caused "exec format error" within the log entry for the database container.

Potential Cause

On investigation, this may be due to an incompatibility with ARM architecture and the jc21/mariadb-aria:10.4 database image, despite the suggestion in the install documentation stating otherwise.

Workaround

I solved this by replacing the jc21/mariadb-aria:10.4 image with webhippie/mariadb:latest.

The webhippie image requires the MYSQL environment variables to be replaced with MARIADB. The updated docker-compose.yml is as follows:

version: "3"
services:
  app:
    image: jc21/nginx-proxy-manager:2
    restart: always
    ports:
      # Public HTTP Port:
      - '80:80'
      # Public HTTPS Port:
      - '443:443'
      # Admin Web Port:
      - '81:81'
    environment:
      # Uncomment this if IPv6 is not enabled on your host
      # DISABLE_IPV6: 'true'
    volumes:
      # Make sure this config.json file exists as per instructions above:
      - ./config.json:/app/config/production.json
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    depends_on:
      - db
  db:
    image: webhippie/mariadb:latest
    restart: always
    environment:
      MARIADB_ROOT_PASSWORD: 'npm'
      MARIADB_DATABASE: 'npm'
      MARIADB_USERNAME: 'npm'
      MARIADB_PASSWORD: 'npm'
    volumes:
      - ./data/mysql:/var/lib/mysql

Additional Information

This was tested using both standard command line docker-compose and Portainer stack deployment. The error existed with deployment on both systems, and was solved using the above workaround on both systems.

I haven't tested this solution for very long, but the containers appear to be stable, I am able to log into the NPM interface and I have been able to enter host entries. I will update if this solution doesn't work for any reason.

[MaxVRAM]

Related open/closed issues on this repo:

458 #446 #310 #298 #269 #483

While some of these issues are closed, I don't believe they have been solved: the currently outlined NPM website instructions in both the quick and full setup guides suggest a broken image for ARM systems. The closed issues were solved by replacing jc21/mariadb-aria:10.4 in the docker-compose.yml with an alternate mariadb image, either:

• webhippie/mariadb:latest
• yobasystems/alpine-mariadb:armhf

While these both appear to be valid workarounds, I proposed that the issue is not fixed as the documentation should reflect a working solution.

[JaneTrix]

subscribed to this issue as their are many people who use arm or low powered devices for docker hosting

[htogether]

still not work properly on armhf.
workaround, tried both db but I think db is ok, npm stop working when I play mp4 from server.

[MaxVRAM]

still not work properly on armhf

@htogether using the workaround or default database?

[htogether]

here is log

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.,
[s6-init] ensuring user provided files have correct perms...exited 0.,
[fix-attrs.d] applying ownership & permissions fixes...,
[fix-attrs.d] done.,
[cont-init.d] executing container initialization scripts...,
[cont-init.d] done.,
[services.d] starting services,
[services.d] done.,
❯ Enabling IPV6 in hosts: /etc/nginx/conf.d,
❯ /etc/nginx/conf.d/default.conf,
❯ /etc/nginx/conf.d/include/ip_ranges.conf,
❯ /etc/nginx/conf.d/include/ssl-ciphers.conf,
❯ /etc/nginx/conf.d/include/block-exploits.conf,
❯ /etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf,
❯ /etc/nginx/conf.d/include/force-ssl.conf,
❯ /etc/nginx/conf.d/include/proxy.conf,
❯ /etc/nginx/conf.d/include/assets.conf,
❯ /etc/nginx/conf.d/include/resolvers.conf,
❯ /etc/nginx/conf.d/production.conf,
❯ Enabling IPV6 in hosts: /data/nginx,
❯ /data/nginx/proxy_host/1.conf,
❯ /data/nginx/proxy_host/2.conf,
❯ /data/nginx/proxy_host/3.conf,
[7/28/2020] [8:23:36 AM] [Migrate ] › ℹ info Current database version: 20200410143840,
[7/28/2020] [8:23:37 AM] [IP Ranges] › ℹ info Fetching IP Ranges from online services...,
[7/28/2020] [8:23:37 AM] [IP Ranges] › ℹ info Fetching https://ip-ranges.amazonaws.com/ip-ranges.json,
[7/28/2020] [8:23:37 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v4,
[7/28/2020] [8:23:37 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v6,
[7/28/2020] [8:23:37 AM] [SSL ] › ℹ info Let's Encrypt Renewal Timer initialized,
[7/28/2020] [8:23:37 AM] [SSL ] › ℹ info Renewing SSL certs close to expiry...,
[7/28/2020] [8:23:37 AM] [IP Ranges] › ℹ info IP Ranges Renewal Timer initialized,
[7/28/2020] [8:23:37 AM] [Global ] › ℹ info Backend PID 209 listening on port 3000 ...,
[7/28/2020] [8:23:45 AM] [Nginx ] › ℹ info Reloading Nginx,
[7/28/2020] [8:23:45 AM] [SSL ] › ℹ info Renew Complete,
QueryBuilder#allowEager method is deprecated. You should use allowGraph instead. allowEager method will be removed in 3.0,
QueryBuilder#eager method is deprecated. You should use the withGraphFetched method instead. eager method will be removed in 3.0,
QueryBuilder#omit is deprecated. This method will be removed in version 3.0,
Duplicate relation "access_list" in a relation expression. You should use "a.[b, c]" instead of "[a.b, a.c]". This will cause an error in objection 2.0,
[7/28/2020] [8:26:24 AM] [Nginx ] › ℹ info Reloading Nginx,
[7/28/2020] [8:26:52 AM] [Nginx ] › ℹ info Reloading Nginx,
[7/28/2020] [8:31:40 AM] [Nginx ] › ℹ info Reloading Nginx,

[MaxVRAM]

@htogether it sounds like a different problem than this thread. Please start a new issue.

[au190]

I have the same issue with verison
docker pull jc21/mariadb-aria:10.4.12
docker pull jc21/mariadb-aria:latest

[au190]

There is another issue on Rpi3 -
error Config file /app/config/production.json cannot be read. Error code is: EISDIR. Error message is: EISDIR: illegal operation on a directory, read Error: Config file /app/config/production.json cannot be read. Error

The resolution is if you have the config.json - in wong location it will create as directory.
This config.json must be on the location where the config is pointing in dcoker-compose.yaml.

ex: copy the config.json to this location : ./volumes/proxy_manager/config.json

• ./volumes/proxy_manager/config.json:/app/config/production.json

[BabzDev]

I have experienced the same issue with my raspberry pi 4. Following these instructions and replacing the jc21/mariadb-aria image for webhippie/mariadb:latest along with the environment variables worked for me!

I also had to create the config.json file in the same location as my docker-compose.yaml file.

{ "database": { "engine": "mysql", "host": "db", "name": "npm", "user": "npm", "password": "npm", "port": 3306 } }

Summary

Using the latest setup instructions on the NPM website, the jc21/mariadb-aria:10.4 image fails on ~Raspberry Pi OS~ (EDIT: just realised this was with a Pi running Ubuntu Server, regardless, ARM architecture) (5.4.0-1013-raspi) with a exec user process caused "exec format error" in the Docker log.

To reproduce

1. Have a Raspberry Pi using ~Raspberry Pi OS~ Ubuntu Server (5.4.0-1013-raspi) or potentially any distro.
2. Create a docker-compose.yml and config.json using the setup guide on the npm website.
3. Deploy using docker-compose up -d.

Result

The stack doesn't load correctly, with errors showing in both the database and app services. Critically, the database service does not allow docker exec -it <container> bash entry, stating that it is currently restarting, and displaying exec user process caused "exec format error" within the log entry for the database container.

Potential Cause

On investigation, this may be due to an incompatibility with ARM architecture and the jc21/mariadb-aria:10.4 database image, despite the suggestion in the install documentation stating otherwise.

Workaround

I solved this by replacing the jc21/mariadb-aria:10.4 image with webhippie/mariadb:latest.

The webhippie image requires the MYSQL environment variables to be replaced with MARIADB. The updated docker-compose.yml is as follows:

version: "3"
services:
  app:
    image: jc21/nginx-proxy-manager:2
    restart: always
    ports:
      # Public HTTP Port:
      - '80:80'
      # Public HTTPS Port:
      - '443:443'
      # Admin Web Port:
      - '81:81'
    environment:
      # Uncomment this if IPv6 is not enabled on your host
      # DISABLE_IPV6: 'true'
    volumes:
      # Make sure this config.json file exists as per instructions above:
      - ./config.json:/app/config/production.json
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    depends_on:
      - db
  db:
    image: webhippie/mariadb:latest
    restart: always
    environment:
      MARIADB_ROOT_PASSWORD: 'npm'
      MARIADB_DATABASE: 'npm'
      MARIADB_USERNAME: 'npm'
      MARIADB_PASSWORD: 'npm'
    volumes:
      - ./data/mysql:/var/lib/mysql

Additional Information

This was tested using both standard command line docker-compose and Portainer stack deployment. The error existed with deployment on both systems, and was solved using the above workaround on both systems.

I haven't tested this solution for very long, but the containers appear to be stable, I am able to log into the NPM interface and I have been able to enter host entries. I will update if this solution doesn't work for any reason.