nginx-proxy-manager: Upgrade to 2.10.1: Error create table `migrations` (permission denied)

@vawaver The problem occurs, if you use the settings from the Setup Instructions - Using MySQL / MariaDB Database If the mapped data folder of the ‘app’ container contains the mapped data folder of the the ‘db’ container. So the ‘app’ container has access to the database files and it seemes that the start process of the ‘app’ container change the ownership for all files and folders, inclusiv the database files.

You have to separate the mapped folders for each container. Example:

version: "3"
services:
  app:
    image: jc21/nginx-proxy-manager:latest
    ...
    ...
    volumes:
      - ./data/app:/data
      - ./data/letsencrypt:/etc/letsencrypt
    ...
    ...
  db:
    image: 'jc21/mariadb-aria:latest'
    ...
    ...
    volumes:
      - ./data/mysql:/var/lib/mysql

You have to move some folders/files to the new ‘app’ subdirectory: access, custom_ssl, logs, nginx, keys.json

check the owner (using ls -ln) of the mysql folder located inside the data folder, is it 100 101 like so ?

drwxr-xr-x 5 100 101 4096 29 mars 18:38 mysql

if not, you can change it using

sudo chown -R 100:101 mysql/

@vawaver The problem occurs, if you use the settings from the Setup Instructions - Using MySQL / MariaDB Database If the mapped data folder of the ‘app’ container contains the mapped data folder of the the ‘db’ container. So the ‘app’ container has access to the database files and it seemes that the start process of the ‘app’ container change the ownership for all files and folders, inclusiv the database files.

You have to separate the mapped folders for each container. Example:

version: "3"
services:
  app:
    image: jc21/nginx-proxy-manager:latest
    ...
    ...
    volumes:
      - ./data/app:/data
      - ./data/letsencrypt:/etc/letsencrypt
    ...
    ...
  db:
    image: 'jc21/mariadb-aria:latest'
    ...
    ...
    volumes:
      - ./data/mysql:/var/lib/mysql

You have to move some folders/files to the new ‘app’ subdirectory: access, custom_ssl, logs, nginx, keys.json

Confirmed working for me. Thanks!

Thanks @Shineson1001 as suggested, moving all files / folders except mysql to a new app folder inside data

And updating the docker compose file worked.

I had to re-apply ownership to the mysql folder as suggsted by @remisharrock

sudo chown -R 100:101 mysql/

Back up and running for now.

Ok I think I got it now,

the issue is the permissions on the mysql folder directory

“[insert your path here]:/var/lib/mysql”

for some reason the “Other User” Value needs to be set to read,write,execute

easier wasy to do this is go to the folder where your mysql data is on the host machine (NOT INSIDE THE CONTAINER), and “chmod 777 -R [mysql folder]”

I know there are hard feelings about security and giving a container full read right permissions in a folder, but if you take other precautions this should be fine, and probably best to back up your volume as well. But this fixed the issue for me, even if I tear the container down and build it back up again with terraform.

I was leery about futzing with permissions, so I segregated the bind mount paths of the two containers, as suggested by Shineson1001 and it works perfectly.

Here is my compose file. In it you can see the volume path change I made within the db container. Update to “latest” happened without error.

version: '3'
services:
  db:
    image: 'jc21/mariadb-aria:latest'
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 'abc123'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'abc'
      MYSQL_PASSWORD: '123'
    volumes:
#     - /home/me/docker/npm/data/mysql:/var/lib/mysql
      - /home/me/docker/npm/mysql:/var/lib/mysql
  app:
    depends_on:
      - db
    image: 'jc21/nginx-proxy-manager:latest'
#   image: 'jc21/nginx-proxy-manager:2.9.22'
    restart: always
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    environment:
      DB_MYSQL_HOST: "db"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "abc"
      DB_MYSQL_PASSWORD: "123"
      DB_MYSQL_NAME: "npm"
#     DISABLE_IPV6: "true"
    volumes:
      - /home/me/docker/npm/data:/data
      - /home/me/docker/npm/letsencrypt:/etc/letsencrypt

ALso did like proposed in https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2774#issuecomment-1489466154 and works!

Issue is solved @2.10.2. Many Thanks!!!

@Shineson1001 What kind of magic do you use? I did as you mentioned above and IT WORKS!!! I wish you all the best!

@ChronoWerX82 I personally ended up converting from a MariaDB to SQLite and this resolved not being able to logon, as well as other startup errors I was facing due to the MariaDB.

So far I’ve found that the docker configuration is easier and it’s an overall easier DB format to manage.

1. First we’re going to prepare the Pre-Requisites to be able to follow these steps. You require the following packages installed: mysqldump, sqlite3 and the script mysql2sqlite a) If you’re on FreeBSD the packages can be installed VIA: pkg install mysqldump sqlite3 b) If you’re on Ubuntu/Debian the packages can be installed VIA: apt-get install mysqldump sqlite3

2. Download the mysql2sqlite script. git clone https://github.com/dumblob/mysql2sqlite.git

3. Export your MariaDB MYSQL Database from your NPM DB Container docker exec -it [db-container-name] mysqldump --user=[mysql-user] --password=[mysql-password] [mysql-db-name] -h 127.0.0.1 > npm-export.sql

4. Convert the .SQL file to a .SQLite file ./mysql2sqlite npm-export.sql | sqlite3 database.sqlite

5. Stop the NPM / DB Containers if they’re running. docker-compose stop [container-name]

6. Copy the database.sqlite file into your container’s persistent storage location. For me and most that followed the default configurations this will be the data directory.

7. Update the docker-compose.yaml and remove every DB_MYSQL_* environment entry.

8. OPTIONAL STEP: Update the docker-compose.yaml and add the following environment entry DB_SQLITE_FILE: "/data/database.sqlite"

Note: This step is OPTIONAL as /data/database.sqlite is the default location NPM will read the database file from. You only really need this line in the YAML if you want to relocate the database.sqlite file. If so, you can adjust the above path to something else.

1. Start your NPM container docker-compose up -d

2. Check the docker Logs for the following line to validate the SQLlite file is being used. Using Sqlite: /data/database.sqlite This can be done easily with the following command: docker compose logs|grep -i database.sqlite

3. Rejoice everything should hopefully be working now.

just realized it myself, poor me … 😃

did add the dependancies and environment and it works now, with the latest image

Been playing around with this issue for a few hours, its definitely and issue with permissions regarding the database user and/or the tables. I’m able to change the permissions on the npm user to get it to work sometimes, but the fix keeps being undone every time i tear the container down and relaunch it via terraform.

To be clear, the container works fine for “Clean” Deployments. But for those who have data, domains, and/or ssl certs they want to carry over the newer version, you are currently out of luck.

Im going to rock 2.9.22 for now until this issue gets fixed, because I have over 30 domains locally I am trying to keep in tact.

check the owner (using ls -ln) of the mysql folder located inside the data folder, is it 100 101 like so ?

drwxr-xr-x 5 100 101 4096 29 mars 18:38 mysql

if not, you can change it using

sudo chown -R 100:101 mysql/

It works for me!

@Shineson1001 Thank you, I was using the same volume structure as mentioned with the issue and moved all app volume related files and folders that were in ./data (except for the mysql/ folder) to a subfolder ./data/app/ instead. Afterwards, I redeployed without any permission related issues.

@Shineson1001 If I get you right, we have to wait for the new version of NGINX that fix this issue. Until then we need to use v2.9.22

check also that inside data/mysql/npm you might want to do this as a superuser (using sudo su) if some files or folders exist , their permissions are like so

-rw-r----- 1 100 101 954 29 mars 17:48 migrations_lock.frm -rw-r----- 1 100 101 16384 29 mars 19:18 migrations_lock.MAD -rw-r----- 1 100 101 16384 29 mars 19:18 migrations_lock.MAI -rw-r----- 1 100 101 16384 29 mars 17:48 migrations.MAD -rw-r----- 1 100 101 16384 29 mars 17:48 migrations.MAI

especially -rw-r----- 1 100 101 at the begining

if not you can go with my previous

sudo chown -R 100:101 mysql/

otherwise it might be a problem with your password in the docker compose file.