Cette discussion Nextcloud/MariaDB de janvier 2026 est l’un des exemples les plus clairs de l’importance de diagnostiquer le réseau des conteneurs couche par couche. L’utilisateur avait installé séparément les applications Nextcloud et MariaDB. MariaDB atteignait un état sain « prête à accepter les connexions », mais Nextcloud échouait lors de la configuration initiale avec Échec de getaddrinfo pour mariadbLa réinstallation des deux applications et la suppression de leurs dossiers n’ont pas modifié l’erreur.
La percée s’est produite lorsque la communauté a testé l’adresse IP Docker réelle du conteneur MariaDB. Nextcloud a immédiatement commencé l’installation. Cela a prouvé que le serveur de base de données, les identifiants et le chemin TCP étaient globalement fonctionnels, tandis que le nom d’hôte mariadb n’était pas résolu depuis le conteneur Nextcloud.
L’utilisateur voulait une base de données MariaDB distincte pour Nextcloud
Les premières réponses évoquaient des solutions telles qu’une image Nextcloud tout-en-un avec PostgreSQL intégré, ou la création manuelle d’une base de données et d’un utilisateur MariaDB via phpMyAdmin. Ces suggestions ne correspondaient pas au problème final. L’utilisateur disposait déjà d’une instance MariaDB fonctionnelle et avait besoin que Nextcloud puisse l’atteindre.
Les journaux MariaDB montraient que la base de données était saine
La communauté a déconseillé à juste titre de modifier à répétition les mots de passe MariaDB et les variables d’environnement une fois la base de données initialisée. De nombreuses images de bases de données n’appliquent les variables d’initialisation qu’à la première création du répertoire de données.
L’hôte de la base de données doit être joignable depuis Nextcloud
Lors de la configuration initiale de Nextcloud, le champ de l’hôte de la base de données peut contenir un nom d’hôte et un port tels que :
mariadb:3306Cela ne fonctionne que lorsque le réseau Docker assure la résolution des noms pour mariadb depuis le conteneur Nextcloud.
Échec de getaddrinfo pour mariadb : s’agit-il d’une erreur de conteneur liée au DNS ?
L’erreur clé était :
php_network_getaddresses : échec de getaddrinfo pour mariadbCela se produit avant que MariaDB puisse accepter ou refuser un nom d’utilisateur et un mot de passe. Si le nom ne peut pas être résolu en adresse IP, les identifiants de la base de données ne sont pas encore évalués.
Le fait que les deux applications indiquent « Bridge » n’a pas résolu la résolution des noms
L’utilisateur a confirmé que les deux applications affichaient un réseau Bridge dans ZimaOS, mais mariadb n’a toujours pas été résolu. Il s’agit d’une nuance importante de Docker : les conteneurs connectés indépendamment au pont par défaut de Docker ne bénéficient pas automatiquement du même comportement de résolution DNS par nom de service que les services connectés à un réseau de pont défini par l’utilisateur.
Par conséquent, « les deux indiquent bridge » ne suffit pas à prouver qu’un conteneur peut résoudre le nom de l’autre.
Une réinstallation propre n’a pas corrigé le comportement réseau
L’utilisateur a désinstallé Nextcloud et MariaDB, supprimé leurs dossiers, puis les a réinstallés depuis zéro. La même erreur de nom d’hôte est réapparue. Ce test négatif est utile, car il montre que le problème ne venait pas simplement d’anciennes données MariaDB ni d’un mot de passe incorrect ponctuel.
Un avertissement d’accès local de Nextcloud constituait un problème distinct
L’utilisateur a trouvé en ligne une suggestion d’activer allow_local_remote_servers. L’application de ce paramètre lors de la configuration initiale a empêché Nextcloud de démarrer correctement. La communauté a expliqué que cette option concernait une autre règle de sécurité de Nextcloud et ne résolvait pas le problème de résolution des noms Docker.
La communauté est ensuite passée à des tests directs du réseau Docker
L’intervenant a demandé les vérifications suivantes :
- si les deux conteneurs étaient en cours d’exécution ;
- le mode réseau réel signalé par Docker ;
- si Nextcloud pouvait résoudre ou envoyer une requête ping à
mariadb; - l’adresse IP Docker actuelle du conteneur MariaDB.
C’est l’étape d’escalade appropriée lorsque les captures d’écran de la configuration ne permettent plus d’expliquer le comportement : tester la connexion depuis le même espace de noms réseau que celui où Nextcloud s’exécute.
L’utilisation de l’adresse IP du conteneur MariaDB a permis d’installer Nextcloud
Le test décisif consistait à remplacer mariadb:3306 temporairement avec l’adresse IP et le port Docker du conteneur MariaDB. L’utilisateur concerné a répondu que Nextcloud s’installait alors.
L’intervenant a résumé clairement le résultat :
-
mariadb:3306a échoué ; - l’adresse IP Docker directe sur le port 3306 a fonctionné immédiatement.
Cela constitue un indice probant d’un problème de résolution du nom du conteneur.
L’adresse IP directe du conteneur constitue une solution de diagnostic valide
L’utilisation de l’adresse IP prouve que la base de données est accessible et permet à l’installation de se poursuivre. Dans le cas décrit, il s’agissait d’une solution de contournement efficace.
Cependant, les adresses IP attribuées automatiquement aux conteneurs peuvent changer lorsqu’un conteneur est recréé, supprimé ou connecté à un autre réseau. Une configuration qui dépend en permanence de 172.17.x.x peut cesser de fonctionner ultérieurement sans aucune modification de la configuration de Nextcloud ou de MariaDB.
Un réseau Docker défini par l’utilisateur constitue une meilleure conception à long terme
L’architecture la plus robuste consiste à connecter Nextcloud et MariaDB au même réseau Docker défini par l’utilisateur et à utiliser un nom de service ou de conteneur stable comme hôte de la base de données. Docker fournit un DNS intégré sur les réseaux définis par l’utilisateur précisément à cette fin.
La modification native des fichiers YAML dans ZimaOS facilite désormais ce type de définition de réseau, contrairement à l’époque de la création de la discussion source. Utilisez le modèle de configuration Compose actuel de ZimaOS lors de la création d’un réseau partagé pour Nextcloud et MariaDB.
Préservez délibérément les données de MariaDB
Si MariaDB contient déjà une base de données Nextcloud fonctionnelle, ne supprimez pas son répertoire de données persistant simplement pour modifier le réseau Docker. L’appartenance au réseau peut être modifiée sans recréer le contenu de la base de données.
Avant toute migration, sauvegardez la base de données et notez l’utilisateur actuel, le nom de la base de données et le mappage des volumes.
Ne désactivez pas les contrôles de sécurité de Nextcloud pour réparer le DNS de Docker
Les paramètres tels que les domaines approuvés, l’accès distant local au serveur et la configuration du proxy inverse protègent Nextcloud au niveau HTTP et applicatif. Ils ne doivent être modifiés que si l’erreur correspondante de Nextcloud l’exige.
A getaddrinfo L’erreur concernant le nom d’hôte de la base de données relève de la couche réseau de Docker.
Un meilleur arbre de diagnostic
- Vérifiez que MariaDB fonctionne et écoute sur le port 3306.
- Vérifiez que la base de données prévue existe et que les identifiants sont connus.
- Testez si Nextcloud peut résoudre le nom d’hôte de la base de données.
- Si la résolution du nom d’hôte échoue, testez l’adresse IP du conteneur de base de données.
- Si l’adresse IP fonctionne, corrigez le réseau Docker plutôt que de modifier les mots de passe de la base de données.
- Déplacez les deux conteneurs vers un réseau stable défini par l’utilisateur afin de bénéficier d’un nom d’hôte durable.
FAQ sur Nextcloud et MariaDB
MariaDB lui-même était-il défaillant ?
Non. Son journal indiquait qu’il était prêt à accepter les connexions.
Que signifiait « getaddrinfo for mariadb failed » ?
Nextcloud ne parvenait pas à résoudre le nom d’hôte de la base de données avant même d’atteindre l’étape d’authentification.
Qu’est-ce qui a confirmé le diagnostic ?
L’utilisation de l’adresse IP Docker directe du conteneur MariaDB a permis à Nextcloud de commencer l’installation.
L’adresse IP directe du conteneur doit-elle être l’hôte permanent de la base de données ?
Cela peut fonctionner, mais un réseau Docker partagé défini par l’utilisateur, avec une résolution stable des noms, est plus robuste.
La réinstallation des deux applications a-t-elle résolu le problème ?
Non. L’utilisateur source a effectué une réinstallation propre et la même erreur de résolution du nom d’hôte est réapparue.
