[GH-ISSUE #509] jc21/mariadb-aria:10.4 database fails on ARM architecture (workaround)

kerem commented

2026-02-26 06:32:50 +03:00

Owner

Originally created by @MaxVRAM on GitHub (Jul 19, 2020).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/509

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

Have a Raspberry Pi using ~~Raspberry Pi OS~~ Ubuntu Server (5.4.0-1013-raspi) or potentially any distro.
Create a docker-compose.yml and config.json using the setup guide on the npm website.
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.

Originally created by @MaxVRAM on GitHub (Jul 19, 2020). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/509 ### 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](https://nginxproxymanager.com/setup/). 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.

kerem

2026-02-26 06:32:50 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-26 06:32:50 +03:00

Author

Owner

@MaxVRAM commented on GitHub (Jul 19, 2020):

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:

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

@MaxVRAM commented on GitHub (Jul 19, 2020): 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](https://nginxproxymanager.com/#quick-setup) and [full setup](https://nginxproxymanager.com/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](https://hub.docker.com/r/webhippie/mariadb/) - [yobasystems/alpine-mariadb:armhf](https://hub.docker.com/r/yobasystems/alpine-mariadb/dockerfile) While these both appear to be valid workarounds, I proposed that the issue is not fixed as the documentation should reflect a working solution.

kerem commented

2026-02-26 06:32:50 +03:00

Author

Owner

@JaneTrix commented on GitHub (Jul 21, 2020):

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

@JaneTrix commented on GitHub (Jul 21, 2020): subscribed to this issue as their are many people who use arm or low powered devices for docker hosting

kerem commented

2026-02-26 06:32:50 +03:00

Author

Owner

@htogether commented on GitHub (Jul 25, 2020):

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.

@htogether commented on GitHub (Jul 25, 2020): 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.

kerem commented

2026-02-26 06:32:50 +03:00

Author

Owner

@MaxVRAM commented on GitHub (Jul 26, 2020):

still not work properly on armhf

@htogether using the workaround or default database?

@MaxVRAM commented on GitHub (Jul 26, 2020): > > > still not work properly on armhf @htogether using the workaround or default database?

kerem commented

2026-02-26 06:32:50 +03:00

Author

Owner

@htogether commented on GitHub (Jul 28, 2020):

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,

@htogether commented on GitHub (Jul 28, 2020): 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,

kerem commented

2026-02-26 06:32:50 +03:00

Author

Owner

@MaxVRAM commented on GitHub (Jul 29, 2020):

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

@MaxVRAM commented on GitHub (Jul 29, 2020): @htogether it sounds like a different problem than this thread. Please start a new issue.

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@au190 commented on GitHub (Oct 21, 2020):

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

@au190 commented on GitHub (Oct 21, 2020): I have the same issue with verison docker pull jc21/mariadb-aria:10.4.12 docker pull jc21/mariadb-aria:latest

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@au190 commented on GitHub (Oct 21, 2020):

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

@au190 commented on GitHub (Oct 21, 2020): 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

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@BabzDev commented on GitHub (Nov 21, 2020):

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

Have a Raspberry Pi using ~~Raspberry Pi OS~~ Ubuntu Server (5.4.0-1013-raspi) or potentially any distro.

Create a docker-compose.yml and config.json using the setup guide on the npm website.

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.

@BabzDev commented on GitHub (Nov 21, 2020): 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](https://nginxproxymanager.com/setup/). > 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.

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@jerimiah797 commented on GitHub (Jan 3, 2021):

I couldn't get it to work with the webhippie mariadb container. Here's what worked for me:

services:
  app:
    container_name: nginx
    image: 'jc21/nginx-proxy-manager:latest'
    restart: always
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    environment:
      DB_MYSQL_HOST: 'db'
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: 'npm'
      DB_MYSQL_PASSWORD: 'npm'
      DB_MYSQL_NAME: 'npm'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    depends_on: 
      - db
  db:
    container_name: maria_for_nginx
    image: 'yobasystems/alpine-mariadb:armhf'
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 'npm'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'npm'
    volumes:
      - ./data/mysql:/var/lib/mysql```

@jerimiah797 commented on GitHub (Jan 3, 2021): I couldn't get it to work with the webhippie mariadb container. Here's what worked for me: ```version: '3' services: app: container_name: nginx image: 'jc21/nginx-proxy-manager:latest' restart: always ports: - '80:80' - '81:81' - '443:443' environment: DB_MYSQL_HOST: 'db' DB_MYSQL_PORT: 3306 DB_MYSQL_USER: 'npm' DB_MYSQL_PASSWORD: 'npm' DB_MYSQL_NAME: 'npm' volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt depends_on: - db db: container_name: maria_for_nginx image: 'yobasystems/alpine-mariadb:armhf' restart: always environment: MYSQL_ROOT_PASSWORD: 'npm' MYSQL_DATABASE: 'npm' MYSQL_USER: 'npm' MYSQL_PASSWORD: 'npm' volumes: - ./data/mysql:/var/lib/mysql```

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@zirophyz commented on GitHub (Jan 14, 2021):

Just to add to this for anyone else reading. I used the linuxserver/mariadb:latest image which worked for me. Running this on an Odroid-C2 Debian Stretch, which is arm64v8, I believe.

@zirophyz commented on GitHub (Jan 14, 2021): Just to add to this for anyone else reading. I used the linuxserver/mariadb:latest image which worked for me. Running this on an Odroid-C2 Debian Stretch, which is arm64v8, I believe.

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@kanintesova commented on GitHub (Jan 25, 2021):

jerimiah797's solution worked for me. And thank you for sharing the docker compose. <3

arm64 ubuntu server 20 LTS, rpi 4

@kanintesova commented on GitHub (Jan 25, 2021): jerimiah797's solution worked for me. And thank you for sharing the docker compose. <3 arm64 ubuntu server 20 LTS, rpi 4

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@urdaibayc commented on GitHub (Jan 28, 2021):

@jerimiah797 Thanks a lot! that also worked for me; raspberry 4, ubuntu server 20.04

@urdaibayc commented on GitHub (Jan 28, 2021): @jerimiah797 Thanks a lot! that also worked for me; raspberry 4, ubuntu server 20.04

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@Xatinni commented on GitHub (Feb 3, 2021):

Same Issue RPI 4 Ubuntu x64

Looks like the base image for the DB container is the incorrect architecture

Docker Inspect extract
Image jc21/mariadb-aria:latest
Labels
alpine-version 3.11.3
architecture amd64/x86_64
build 09-Mar-2020
com.docker.compose.config-hash 1076c9420bfcb01e3089edcf92904e330ea9a4ad

Container Logs
standard_init_linux.go:211: exec user process caused "exec format error"

@Xatinni commented on GitHub (Feb 3, 2021): Same Issue RPI 4 Ubuntu x64 Looks like the base image for the DB container is the incorrect architecture Docker Inspect extract Image jc21/mariadb-aria:latest Labels alpine-version 3.11.3 **architecture amd64/x86_64** build 09-Mar-2020 com.docker.compose.config-hash 1076c9420bfcb01e3089edcf92904e330ea9a4ad Container Logs standard_init_linux.go:211: exec user process caused "exec format error"

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@Xatinni commented on GitHub (Feb 3, 2021):

I think a new mariadb build/push with the latest yobasystems build will fix this problem, I sucessfully pushed a new build to Docker Hub - guyneale/maria-aria:latest and then redeployed the stack using the new image

1 | 0 B | ARG BUILD_DATE
2 | 0 B | ARG VCS_REF
3 | 0 B | LABEL maintainer=Dominic Taylor dominic@yobasystems.co.uk architecture=arm64v8/aarch64 alpine-version=3.12.0 build=14-Oct-2020 org.opencontainers.image.title=alpine org.opencontainers.image.description=Docker image running on Alpine Linux org.opencontainers.image.authors=Dominic Taylor dominic@yobasystems.co.uk org.opencontainers.image.vendor=Yoba Systems org.opencontainers.image.version=v3.12.0 org.opencontainers.image.url=https://hub.docker.com/r/yobasystems/alpine/ org.opencontainers.image.source=https://github.com/yobasystems/alpine org.opencontainers.image.revision=933dc859 org.opencontainers.image.created=1602668665
4 | 5.3 MB | ADD file:53d23a97aa8cd66814c115c8e575c9cbc0b720f963384aa4c84614f2946e1275 in /
5 | 0 B | CMD ["/bin/sh"]
6 | 0 B | ARG BUILD_DATE
7 | 0 B | ARG VCS_REF
8 | 0 B | LABEL maintainer=Dominic Taylor dominic@yobasystems.co.uk architecture=arm64v8/aarch64 mariadb-version=10.4.15 alpine-version=3.12.0 build=14-Oct-2020 org.opencontainers.image.title=alpine-mariadb org.opencontainers.image.description=MariaDB Docker image running on Alpine Linux org.opencontainers.image.authors=Dominic Taylor dominic@yobasystems.co.uk org.opencontainers.image.vendor=Yoba Systems org.opencontainers.image.version=v10.4.15 org.opencontainers.image.url=https://hub.docker.com/r/yobasystems/alpine-mariadb/ org.opencontainers.image.source=https://github.com/yobasystems/alpine-mariadb org.opencontainers.image.revision=cbe54513 org.opencontainers.image.created=1602683628
9 | 212.6 MB | |2 BUILD_DATE=1602683628 VCS_REF=cbe54513 RUN apk add --no-cache mariadb mariadb-client mariadb-server-utils pwgen && rm -f /var/cache/apk/*
10 | 3.1 kB | ADD file:bd22c55f38dc563ac1cee542bd1066bf66454353b7a81b0f1e02d666955ba4fb in /scripts/run.sh
11 | 3.1 kB | |2 BUILD_DATE=1602683628 VCS_REF=cbe54513 RUN mkdir /docker-entrypoint-initdb.d && mkdir /scripts/pre-exec.d && mkdir /scripts/pre-init.d && chmod -R 755 /scripts
12 | 0 B | EXPOSE 3306
13 | 0 B | VOLUME [/var/lib/mysql]
14 | 0 B | ENTRYPOINT ["/scripts/run.sh"]
15 | 0 B | LABEL maintainer=Jamie Curnow jc@jc21.com
16 | 159 B | COPY file:e517d6f27ae51dd175b6d9dd704f92563213a4a8869c69619a9502c24e0faefb in .
17 | 159 B | RUN cat /00_aria.cnf >> /etc/mysql/my.cnf

@Xatinni commented on GitHub (Feb 3, 2021): I think a new mariadb build/push with the latest yobasystems build will fix this problem, I sucessfully pushed a new build to Docker Hub - guyneale/maria-aria:latest and then redeployed the stack using the new image 1 | 0 B | ARG BUILD_DATE 2 | 0 B | ARG VCS_REF 3 | 0 B | LABEL maintainer=Dominic Taylor <dominic@yobasystems.co.uk> architecture=arm64v8/aarch64 alpine-version=3.12.0 build=14-Oct-2020 org.opencontainers.image.title=alpine org.opencontainers.image.description=Docker image running on Alpine Linux org.opencontainers.image.authors=Dominic Taylor <dominic@yobasystems.co.uk> org.opencontainers.image.vendor=Yoba Systems org.opencontainers.image.version=v3.12.0 org.opencontainers.image.url=https://hub.docker.com/r/yobasystems/alpine/ org.opencontainers.image.source=https://github.com/yobasystems/alpine org.opencontainers.image.revision=933dc859 org.opencontainers.image.created=1602668665 4 | 5.3 MB | ADD file:53d23a97aa8cd66814c115c8e575c9cbc0b720f963384aa4c84614f2946e1275 in / 5 | 0 B | CMD ["/bin/sh"] 6 | 0 B | ARG BUILD_DATE 7 | 0 B | ARG VCS_REF 8 | 0 B | LABEL maintainer=Dominic Taylor <dominic@yobasystems.co.uk> **architecture=arm64v8/aarch64** mariadb-version=10.4.15 alpine-version=3.12.0 build=14-Oct-2020 org.opencontainers.image.title=alpine-mariadb org.opencontainers.image.description=MariaDB Docker image running on Alpine Linux org.opencontainers.image.authors=Dominic Taylor <dominic@yobasystems.co.uk> org.opencontainers.image.vendor=Yoba Systems org.opencontainers.image.version=v10.4.15 org.opencontainers.image.url=https://hub.docker.com/r/yobasystems/alpine-mariadb/ org.opencontainers.image.source=https://github.com/yobasystems/alpine-mariadb org.opencontainers.image.revision=cbe54513 org.opencontainers.image.created=1602683628 9 | 212.6 MB | \|2 BUILD_DATE=1602683628 VCS_REF=cbe54513 RUN apk add --no-cache mariadb mariadb-client mariadb-server-utils pwgen && rm -f /var/cache/apk/* 10 | 3.1 kB | ADD file:bd22c55f38dc563ac1cee542bd1066bf66454353b7a81b0f1e02d666955ba4fb in /scripts/run.sh 11 | 3.1 kB | \|2 BUILD_DATE=1602683628 VCS_REF=cbe54513 RUN mkdir /docker-entrypoint-initdb.d && mkdir /scripts/pre-exec.d && mkdir /scripts/pre-init.d && chmod -R 755 /scripts 12 | 0 B | EXPOSE 3306 13 | 0 B | VOLUME [/var/lib/mysql] 14 | 0 B | ENTRYPOINT ["/scripts/run.sh"] 15 | 0 B | LABEL maintainer=Jamie Curnow <jc@jc21.com> 16 | 159 B | COPY file:e517d6f27ae51dd175b6d9dd704f92563213a4a8869c69619a9502c24e0faefb in . 17 | 159 B | RUN cat /00_aria.cnf >> /etc/mysql/my.cnf

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@jc21 commented on GitHub (Feb 8, 2021):

Just fixed a problem with jc21/mariadb-aria where all architectures listed where in fact the amd64 build. All the arm builds should be correct now. Please open an issue on the github project for mariadb-aria if there are more problems.

@jc21 commented on GitHub (Feb 8, 2021): Just fixed a problem with [jc21/mariadb-aria](https://hub.docker.com/repository/docker/jc21/mariadb-aria) where all architectures listed where in fact the amd64 build. All the arm builds should be correct now. Please open an issue on the github project for [mariadb-aria](https://github.com/jc21/docker-mariadb-aria) if there are more problems.

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@inthreedee commented on GitHub (Feb 13, 2021):

@jc21 Related: Please also add armv8 for the Raspberry Pi 4 (https://github.com/jc21/nginx-proxy-manager/issues/602)

@inthreedee commented on GitHub (Feb 13, 2021): @jc21 Related: Please also add armv8 for the Raspberry Pi 4 (https://github.com/jc21/nginx-proxy-manager/issues/602)

kerem commented

2026-02-26 06:32:51 +03:00

Author

Owner

@Aftabx commented on GitHub (Jun 7, 2021):

@jc21 Related: Please also add armv8 for the Raspberry Pi 4 (#602)

indeed @jc21 , it would be great if you add armv8 for Raspberry pi 4 :-)

@Aftabx commented on GitHub (Jun 7, 2021): > @jc21 Related: Please also add armv8 for the Raspberry Pi 4 (#602) indeed @jc21 , it would be great if you add armv8 for Raspberry pi 4 :-)

kerem referenced this issue

2026-02-26 07:38:36 +03:00

[PR #435] [MERGED] Don't use duplicate relations when eager-loading access list items and clients. #3246

Rows
Columns

[GH-ISSUE #509] jc21/mariadb-aria:10.4 database fails on ARM architecture (workaround) #434

Summary

To reproduce

Result

Potential Cause

Workaround

Additional Information

Summary

To reproduce

Result

Potential Cause

Workaround

Additional Information