MySQL : résoudre l’erreur “Access denied for user debian-sys-maint@localhost”

Publié le 16 mai 2026 by Matt Biscay · Lecture: 7 minutes

Lors de la migration de bases de données d’un serveur à l’autre, j’ai déplacé la base mysql, qui contient les utilisateurs, les privilèges et une partie de la configuration interne du serveur SQL.

Sur le papier, cela évite de recréer tous les comptes SQL à la main. En pratique, cela peut aussi déplacer des comptes système propres à l’ancien serveur et casser les comptes de maintenance du nouveau.

C’est ainsi que l’on peut tomber sur cette erreur au démarrage ou à l’arrêt de MySQL :

Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)Code language: JavaScript (javascript)

Ou encore :

/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'Code language: JavaScript (javascript)

Le problème vient généralement d’un décalage entre l’utilisateur SQL debian-sys-maint présent dans MySQL/MariaDB et le mot de passe stocké dans le fichier système /etc/mysql/debian.cnf.

À quoi sert debian-sys-maint ?

Sur certaines anciennes installations Debian/Ubuntu, le paquet MySQL créait un utilisateur spécial nommé debian-sys-maint.

Cet utilisateur servait aux scripts de maintenance du paquet : vérifier l’état du serveur, recharger certaines informations, arrêter proprement MySQL, effectuer certaines tâches administratives, etc.

Son mot de passe était stocké dans :

/etc/mysql/debian.cnf

Le wiki Evolix résume bien ce comportement : sur Debian 10 et inférieur, certaines tâches passent par l’utilisateur SQL debian-sys-maint, avec un mot de passe stocké dans /etc/mysql/debian.cnf. Evolix Wiki : Howto MySQL

Sur des systèmes plus récents, surtout avec MariaDB et l’authentification par socket Unix, ce compte peut ne plus être présent ou ne plus être nécessaire. Il faut donc adapter le diagnostic à votre version réelle de MySQL/MariaDB.

Composer : résoudre file_put_contents composer.json Permission denied

Publié le 15 mai 2026 by Matt Biscay · Lecture: 7 minutes

J’ai récemment joué avec Composer pour gérer les dépendances d’un plugin WordPress, et il faut reconnaître que l’outil simplifie énormément la gestion du code tiers.

Lors d’un changement de Mac, après import de mes anciennes données sur une nouvelle machine, j’ai obtenu ce message d’erreur :

Composer: file_put_contents(./composer.json): failed to open stream: Permission deniedCode language: HTTP (http)

Cette erreur signifie que Composer essaie d’écrire dans composer.json, ou dans le dossier courant, mais que l’utilisateur qui exécute la commande n’a pas les droits nécessaires.

Le problème peut venir du dossier du projet, du fichier composer.json, du cache Composer, du dossier global Composer, ou d’un ancien usage de sudo composer qui a laissé des fichiers appartenant à root.

Comprendre l’erreur

Le message important est :

failed to open stream: Permission denied

Composer n’arrive pas à écrire dans le fichier demandé. Dans l’exemple :

file_put_contents(./composer.json)

Composer tente d’écrire dans composer.json, dans le dossier courant.

Cela arrive souvent après :

une migration de Mac ou de PC ;
une restauration depuis une sauvegarde ;
un changement d’utilisateur système ;
une commande Composer lancée avec sudo ;
un projet copié depuis un autre compte ;
un dossier synchronisé via Dropbox, iCloud, NAS ou disque externe ;
un projet créé dans un dossier appartenant à root ou à un autre utilisateur.

Donc avant de corriger au marteau, on vérifie exactement quel dossier pose problème. Le marteau marche, certes, mais il a une mauvaise finesse de diagnostic.

Serveur dédié : installation de MariaDB 10.3 photo

Serveur dédié : installer MariaDB sur Debian 13

Publié le 14 mai 2026 by Matt Biscay · Lecture: 6 minutes

Nous allons voir comment installer MariaDB proprement sur un serveur Debian moderne, avec deux approches :

installer MariaDB depuis les dépôts Debian, solution la plus simple et la plus stable ;
installer MariaDB depuis le dépôt officiel MariaDB, si l’on veut choisir précisément une branche.

Pour un serveur Debian 13 Trixie classique, la première méthode suffit dans la majorité des cas : Debian fournit déjà MariaDB 11.8, qui correspond à la branche LTS actuelle chez MariaDB. MariaDB liste notamment MariaDB 11.8.6 comme version stable GA récente. MariaDB : latest releases

Méthode recommandée : installer MariaDB depuis Debian

Sur Debian 13 Trixie, le plus simple consiste à utiliser les dépôts Debian officiels.

On met d’abord le système à jour :

sudo apt update
sudo apt upgrade

Puis on installe MariaDB :

sudo apt install mariadb-server mariadb-client

On vérifie ensuite la version installée :

mariadb --version
mariadbd --version

Sur Debian 13, le paquet mariadb-server est actuellement fourni en version 1:11.8.6-0+deb13u1, selon la fiche officielle du paquet Debian. Debian packages : mariadb-server dans Trixie

On vérifie le statut du service :

systemctl status mariadb --no-pager

Si nécessaire, on l’active au démarrage :

sudo systemctl enable --now mariadb

Cette méthode est celle que je recommande pour la plupart des serveurs WordPress, WooCommerce, applications PHP ou sites classiques. Vous bénéficiez des mises à jour de sécurité Debian, sans empiler inutilement des dépôts externes.