[Résolu][Résolu] Problème lors de l'installation de mariaDB avec Docker (Permission Denied)

[Elrohir]

Bonjour à tous,

Je tente d'installer MariaDB via Docker sur mon NAS mais lorsque celui-ci démarre il s'arrête quasiment tout de suite.
Il m'indique dans le log qu'il n'a pas les autorisations nécessaires pour écrire dans le dossier que je lui ai spécifié alors que Wordpress lui par exemple écris normalement dans son dossier.

 

2024/02/05 23:15:32	stderr	2024-02-05 23:15:32 0 [ERROR] Aborting
2024/02/05 23:15:32	stderr	/usr/sbin/mariadbd: Can't change dir to '/var/lib/mysql/' (Errcode: 13 "Permission denied")
2024/02/05 23:15:32	stderr	2024-02-05 23:15:32 0 [Warning] Can't create test file '/var/lib/mysql/wordpress-db.lower-test' (Errcode: 13 "Permission denied")

mariaDB:latest
DSM : DSM 7.2.1-69057 Update 4
Container Manager Vers. 20.10.23-1437
NAS : DS923+

Est-ce que d'autres personnes sont dans le même cas que moi lors de l'installation de mariaDB via Docker ?
Merci.

WordPress-DB-blog.html

Modifié le 24 février par Elrohir

[Invité]

Bonjour,

Tu as installé MariaDB en package seul ou il (DB) est intégré avec WP (si tu l'a installé en Docker) ?

Sélectionne le dossier de l'app (dans le dossier partagé "docker") concerné et donne lui les autorisations -> permission "System" lire et écrire.

Si c'est suite à une mise à jour (image par ex), redonne les autorisations, puis si tu as Portainer, sélectionne stack (si c'est un WP complet par un script dans Portainer) ou container (suivant ton install) et upgrade en repoussant l'image.

J'ai plusieurs sites en WP Docker et Apps et quand il y a une mise à jour, je dois procéder (qques fois) à la manip de réactualisation indiqué ci-dessus.

 

Modifié le 8 février par morgyann

[Elrohir]

Il y a 7 heures, morgyann a dit :

Bonjour,

Bonjour,

Citation

Tu as installé MariaDB en package seul ou il (DB) est intégré avec WP (si tu l'a installé en Docker) ?

J'ai une stack qui télécharge et configures les images de wordpress et de mariaDB (et de phpMyAdmin)

Citation

Sélectionne le dossier de l'app (dans le dossier partagé "docker") concerné et donne lui les autorisations -> permission "System" lire et écrire.

J'ai rajouter les permissions comme indiqués et les fichiers de mariaDB ont bien été écris cette fois.
Par contre le container de mariaDB à le statut unhealthy sur portainer
Je vais pouvoir continuer a mon installation, merci beaucoup pour l'aide.

Modifié le 8 février par Elrohir

[Invité]

il y a 38 minutes, Elrohir a dit :

Par contre le container de mariaDB à le statut unhealthy sur portainer

 ... mais si tu installes WP en docker, finis sa conf et, une fois terminée ... retourne voir si tout est sain -> la conf de la DB se finalise lors de la conf de WP.

[Elrohir]

J'ai terminé mon installation de Wordpress et le container de mariaDB reste toujours en unhealthy alors que ça semble fonctionner correctement

Modifié le 9 février par Elrohir

[Invité]

Il y a 11 heures, Elrohir a dit :

container de mariaDB reste toujours en unhealthy

Peut être régler ce souci, si tu veux démarrer du bon pied ...

Quelques pistes :

- soit un probléme de script dans l'éditeur de ta pile

-soit un problème d'autorisation d'accès au dossier WP -> vérifie "le propriétaire" (sans appliquer aux sous dossiers) - et "Permission" (l'admin propriétaire -> contrôle total/lire/écrire) + (System -> lire & écrire) + (Everyone -> lire) appliquer aux sous dossiers

Puis upgrader la pile en poussant les images dans Portainer -> regarder si le déploiement s'est bien passé (si non -> voir en haut à droite la raison de ce qui cloche). 

[Elrohir]

il y a 36 minutes, morgyann a dit :

Peut être régler ce souci, si tu veux démarrer du bon pied ...

-soit un problème d'autorisation d'accès au dossier WP -> vérifie "le propriétaire" (sans appliquer aux sous dossiers) - et "Permission" (l'admin propriétaire -> contrôle total/lire/écrire) + (System -> lire & écrire) + (Everyone -> lire) appliquer aux sous dossiers

Quand je regarde les permissions du dossier où est installer Wordpress j'ai en Propriétaire 33 qui s'affiche, pareil dans les permissions c'est étrange non ?
J'ajoute les permissions mais est-ce que je change le Propriétaire ?

[Invité]

1. Dans propriétaire tu mets (sélectionne) l'admin qui créé (toi je suppose)

2. Tu sauvegardes ( sans cocher appliquer à ce dossier ...)

3. Dans permission tu enlèves "33" et tu ajoutes l'admin proprio (toi) et system et tu suis ce que j'ai indiqué + haut :

il y a 47 minutes, morgyann a dit :

-soit un problème d'autorisation d'accès au dossier WP -> vérifie "le propriétaire" (sans appliquer aux sous dossiers) - et "Permission" (l'admin propriétaire -> contrôle total/lire/écrire) + (System -> lire & écrire) + (Everyone -> lire) appliquer aux sous dossiers

Puis upgrader la pile en poussant les images dans Portainer -> regarder si le déploiement s'est bien passé (si non -> voir en haut à droite la raison de ce qui cloche). 

 

[Elrohir]

il y a une heure, morgyann a dit :

-soit un problème d'autorisation d'accès au dossier WP -> vérifie "le propriétaire" (sans appliquer aux sous dossiers) - et "Permission" (l'admin propriétaire -> contrôle total/lire/écrire) + (System -> lire & écrire) + (Everyone -> lire) appliquer aux sous dossiers

Puis upgrader la pile en poussant les images dans Portainer -> regarder si le déploiement s'est bien passé (si non -> voir en haut à droite la raison de ce qui cloche). 

C'est fait mais le résultat est le même. Et je n'ai eu aucun message d'erreur dans Portainer, pour lui tout c'est bien dérouler

Peut-être un problème dans ma stack ?

version: '3.9'
services:
  wordpress:
    image: wordpress:latest
    container_name: WordPress-blog
    hostname: wordpress
    healthcheck:
     test: curl -f http://localhost:80/ || exit 1
    ports:
      - 8181:80
    depends_on:
      db:
        condition: service_started
      redis:
        condition: service_healthy
      phpmyadmin:
        condition: service_healthy
    volumes:
      - /volume1/www/blog/html:/var/www/html:rw
      - /volume1/www/blog/wordpress.ini:/usr/local/etc/php/conf.d/wordpress.ini:rw
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: elrohir_blog
      WORDPRESS_DB_PASSWORD: mysql_password
      WORDPRESS_DB_NAME: blog
    restart: on-failure:5

  db:
    image: mariadb:latest
    container_name: WordPress-DB-blog
    security_opt:
      - no-new-privileges:true
    hostname: wordpress-db
    healthcheck:
     test: ["CMD-SHELL", "mysqladmin ping -P 3306 -pmysql_root_password | grep 'mysqld is alive' || exit 1"]
    environment:
      MYSQL_DATABASE: blog
      MYSQL_USER: elrohir_blog
      MYSQL_PASSWORD: mysql_password
      MYSQL_ROOT_PASSWORD: mysql_root_password
      TZ: Europe/Paris
    volumes:
      - /volume1/www/blog/db:/var/lib/mysql:rw
    restart: on-failure:5

  redis:
    image: redis:latest
    hostname: wordpress-redis
    container_name: WordPress-REDIS-blog
    user: 1026:100
    healthcheck:
     test: ["CMD-SHELL", "redis-cli ping || exit 1"]
    volumes:
      - /volume1/www/blog/redis:/data:rw
    environment:
      TZ: Europe/Paris
    restart: on-failure:5
      
  phpmyadmin:
    image: phpmyadmin:latest
    hostname: wordpress-phpmyadmin
    healthcheck:
     test: curl -f http://localhost:80/ || exit 1
    container_name: WordPress-phpMyAdmin-blog
    ports:
      - 2500:80
    environment:
     PMA_HOST: wordpress-db
     PMA_PORT: 3306
    restart: on-failure:5

 

[Invité]

Il y a 2 heures, Elrohir a dit :

volumes:
      - /volume1/www/blog/db:/var/lib/mysql:rw

Tu as mis ton dossier dans "web" et pas dans le dossier "docker" ?

Le dossier "web" est par défaut pour web station et le dossier "docker" pour les apps docker.

Si tu développes d'autres apps docker et/ou des apps via WebStation, il serait + judicieux quelles soient classées et affectées dans les bons dossiers réf.

Il vaut mieux que tu redémarres à zéro en recréant ton dossier WP et ses sous-dossiers dans le dossier partagé "docker" (vu que tu n'as pas commencé ton WP).

Le transfert de dossier risque de donner à nouveau des problème d'authorisation si tu n'as pas encore la maîtrise du transfert de ce type d'app docker.

Modifié le 9 février par morgyann

[Invité]

Il y a 2 heures, Elrohir a dit :

container_name: WordPress-blog
    hostname: wordpress

Si tu as appelé ton dossier WP -> blog

il vaut mieux pour ... name : Blog et pour hostname: blog 

Il y a 2 heures, Elrohir a dit :

WORDPRESS_DB_PASSWORD: mysql_password

un vrai mot de passe ainsi que pour le root (tu peux garder le même)

 

Il y a 2 heures, Elrohir a dit :

container_name: WordPress-DB-blog
    security_opt:
      - no-new-privileges:true
    hostname: wordpress-db

Par ex : ...name: Blog-DB et hostname: blog-db

Il y a 2 heures, Elrohir a dit :

hostname: wordpress-redis
    container_name: WordPress-REDIS-blog

...name: Blog-REDIS et hostname: blog-redis

 

Il y a 2 heures, Elrohir a dit :

hostname: wordpress-phpmyadmin
    healthcheck:
     test: curl -f http://localhost:80/ || exit 1
    container_name: WordPress-phpMyAdmin-blog

...name: Blog-phpMyAdmin et hostname: blog-phpmyadmin

 

Puis faire et vérifier les correspondances des noms sur l'ensemble du script.

Donner un nom spécifique à ton dossier WP (par ex "blog" à la place de "wordpress") ainsi qu'aux containers dépendants, est interressant si tu développes et héberges d'autres WP en docker -> celà te permet de les identifier au niveau des dossiers, des containers et des scripts.

Attention : si tu as nommé ton dossier WP -> "blog" (à la place de "wordpress"), les sous-dossiers doivent garder les appelations "db" et "redis" et, le fichier "wordpress.ini" à appeler "uploads.ini" (si c'est bien pour l'upload et à modifier dans le script) pour l'identifier -> si tu dois mettre par la suite d'autres fichiers .ini (par ex. php.ini)

Modifié le 9 février par morgyann

[Elrohir]

Il y a 1 heure, morgyann a dit :

Tu as mis ton dossier dans "web" et pas dans le dossier "docker" ?

Le dossier "web" est par défaut pour web station et le dossier "docker" pour les apps docker.

Si tu développes d'autres apps docker et/ou des apps via WebStation, il serait + judicieux quelles soient classées et affectées dans les bons dossiers réf.

Il vaut mieux que tu redémarres à zéro en recréant ton dossier WP et ses sous-dossiers dans le dossier partagé "docker" (vu que tu n'as pas commencé ton WP).

Le transfert de dossier risque de donner à nouveau des problème d'authorisation si tu n'as pas encore la maîtrise du transfert de ce type d'app docker.

Non, le dossier "www" est un dossier partagé que j'ai crée, WebStation n'est pas installé.
Je peux déplacé mon installation

il y a une heure, morgyann a dit :

Attention : si tu as nommé ton dossier WP -> "blog" (à la place de "wordpress"), les sous-dossiers doivent garder les appelations "db" et "redis" et, le fichier "wordpress.ini" à appeler "uploads.ini" (si c'est bien pour l'upload et à modifier dans le script) pour l'identifier -> si tu dois mettre par la suite d'autres fichiers .ini (par ex. php.ini)

Mon dossier actuellement est configurer comme tel :

www > blog > html (avec wordpress à l'intérieur)
           > redis (avec redis dedans)
           > db (avec mariaDB à l'intérieur
           > wordpress.ini

Edit : J'ai fait les modif' sur la stack comme indiqués avec les chemins des dossiers modifiés aussi, j'attend que la stack se termine

Modifié le 9 février par Elrohir

[Invité]

il y a 9 minutes, Elrohir a dit :

Non, le dossier "www" est un dossier partagé que j'ai crée, WebStation n'est pas installé.
Je peux déplacé mon installation

Quand tu as installé "Container Manager" un dossier "docker" partagé s'est créé. C'est celui-ci qu'il faut utiliser. 

Si tu déplaces ton install, il faut recréer un nouveau dossier principal (dans docker) que tu appelles "blog" et tu ne transfères que les sous-dossiers et fichiers.

Il faudra que tu changes les chemins du script -> mettre "docker" à la place de "www" + les autres modifs que je t'ai indiquées.

Il faudra reprocéder à la procédure indiquée + haut (autorisations + update du script) et revérifier les auth après l'update

[Elrohir]

J'ai relancé le script et mariaDB s'est bien installé avec les fichiers dans le dossier mais est toujours unhealthy malheureusement
Je peux t'envoyer un log de mariaDB si tu veux mais le message d'erreur est toujours le même qu'avant

Citation

/bin/sh: 1: mysqladmin: not found

 

[Invité]

Je ne serais trop de te conseiller de développer une installation propre et saine (et de la sauvegarder quand elle sera en prod).

Je t'invite à redémarrer à zéro (15 / 30 minutes d'install complète) et de suivre à la lettre ce tuto :

https://mariushosting.com/how-to-install-wordpress-on-your-synology-nas/

Avec la modification suivante -> mettre sur le script "wordpress:latest" (à la place de php8.2 -> il y a des fonctions qui fonctionnent mal avec cette image).

• Faire la correspondance du NDD dans sécurité -> certificat
• Vérifier les autorisations du dossier WP (vu + haut) après le déploiement de la pile et avant de remplir la "fiche" de renseignement pour activer WP.
• Vérifier une fois le wp-admin ouvert -> réinstaller la dernière version wp (1er onglet mise à jour) pour voir si les permissions sont bonnes + déterminer les liens en permaliens.
• Voir sur ce site (Marius) comment activer REDIS et CRON (si besoin ou pas suivant ton projet et tes plugins WP).

[.Shad.]

@Elrohir Utilise l'image MariaDB de Linuxserver, elle est bien plus adaptée pour l'utilisation avec un NAS grâce au mapping de user/groupe (PUID/PGID).

Pas le temps aujourd'hui de lire le sujet en entier pour voir ce que tu as déjà fait, mais je lis ça demain. 🙂

[Invité]

Il y a 4 heures, .Shad. a dit :

l'image MariaDB de Linuxserver, elle est bien plus adaptée pour l'utilisation avec un NAS grâce au mapping de user/groupe (PUID/PGID)

Pour ma part, j'utilise "mariadb:lastet" pour tous mes WP Docker en revanche, mes auth / liaison de connexion "sautent" (quelques fois - pas souvent) lors des mises à jour -> obligé de relancer la pile en repoussant l'image.

L'image que tu proposes est bien identifiée comme celle-ci (en rajoutant l'environment qui suit) et permet-elle d'éviter cette manip à chaque mise à jour ? :

image: lscr.io/linuxserver/mariadb:latest

container_name: xxx-DB

environment:

user: 1026:100 

Modifié le 10 février par morgyann

[Invité]

@.Shad. je viens de tester l'image  lscr.io/linuxserver/mariadb:latest en remplacement de mariadb, sur un WP en développement -> plugin bloqué (smtp), impossible de réinstaller la dernière version de wp sur le panneau wp-admin et d'activer de nouveau plug-in. Peut-être que cette image doit-être installée lors de la création de la pile et ne peut-être changée (compatibilité) par une autre (comme cela peut être la cas avec d'autres images). Je suis revenu à mariadb et tout est revenu dans l'ordre ...

[.Shad.]

@morgyann Cette image n'est pas configurable qu'au déploiement, mais à tout moment via le terminal ou via PMA.
Tu as fait un dump de ta base de données dans l'image MariaDB officielle et l'as importé dans MariaDB version LS ?

Après si ça marche bien chez toi pas nécessaire de changer, c'est juste que les images LS facilitent la vie pour le déploiement sur un Linux modifié comme sur nos NAS.

@Elrohir Quel user exécute MariaDB dans ta config d'origine ? root ? tu as essayé de chmodder les dossiers pour voir si ça fonctionnait mieux ?

[.Shad.]

@Elrohir Ca donne quoi ton problème ?

[Elrohir]

Le 13/02/2024 à 7:10 AM, .Shad. a dit :

@Elrohir Ca donne quoi ton problème ?

Désolé j'était pas revenu depuis que j'ai réglé le soucis.
Tout fonctionne correctement et vert depuis que j'ai enlever :

Citation

    healthcheck:
     test: ["CMD-SHELL", "mysqladmin ping -P 3306 -pmysql_root_password | grep 'mysqld is alive' || exit 1"]

(Ce WE je m'attaque à l'installation et la configuration d'un VPN pour accéder a mon réseau local depuis mon iPad et mon iPhone quand je ne suis pas à la maison)

Modifié le 24 février par Elrohir

[Lelolo]

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.