Den här Nextcloud/MariaDB-tråden från januari 2026 är ett av de tydligaste exemplen på varför containerkommunikation bör felsökas lager för lager. Användaren installerade separata Nextcloud- och MariaDB-appar. MariaDB nådde ett friskt tillstånd med ”redo för anslutningar”, men Nextcloud misslyckades under den första konfigurationen med getaddrinfo for mariadb failedAtt installera om båda apparna och ta bort deras mappar ändrade inte felet.
Genombrottet kom när communityn testade MariaDB-containerns faktiska Docker-IP. Nextcloud började installeras direkt. Det bevisade att databasservern, autentiseringsuppgifterna och TCP-vägen i grunden fungerade, medan värdnamnet mariadb kunde inte namnupplösas från Nextcloud-containern.
Användaren ville ha en separat MariaDB-databas för Nextcloud
Tidiga svar diskuterade alternativ som en allt-i-ett-Nextcloud-avbild med PostgreSQL inkluderat, eller att manuellt skapa en MariaDB-databas och användare via phpMyAdmin. Dessa förslag var inte det slutliga problemet. Användaren hade redan MariaDB igång och behövde få Nextcloud att nå den.
MariaDB-loggarna visade att databasen var frisk
Communityn avrådde med rätta från att upprepade gånger ändra MariaDB-lösenord och miljövariabler efter att databasen redan hade initierats. Många databaskavbilder använder initieringsvariablerna endast när datakatalogen skapas första gången.
Databasvärden måste vara nåbar från Nextcloud
Under den första konfigurationen av Nextcloud kan databasvärdsfältet innehålla ett värdnamn och en port, till exempel:
mariadb:3306Det fungerar bara när Dockers nätverk tillhandahåller namnupplösning för mariadb från Nextcloud-containern.
getaddrinfo for mariadb failed är ett DNS-liknande containerfel
Det centrala felet var:
php_network_getaddresses: getaddrinfo for mariadb failedDetta inträffar innan MariaDB kan godkänna eller avvisa ett användarnamn och lösenord. Om namnet inte kan översättas till en IP-adress har databasautentiseringsuppgifterna ännu inte börjat utvärderas.
Att båda apparna visade ”Bridge” löste inte namnupplösningen
Användaren bekräftade att båda applikationerna visade bryggnätverk i ZimaOS, men mariadb löste fortfarande inte problemet. Det här är en viktig Docker-nyans: containrar som ansluts separat till Dockers standardbrygga får inte automatiskt samma DNS-beteende med tjänstenamn som tjänster anslutna till ett användardefinierat bryggnätverk.
Därför räcker det inte som bevis att ”båda anger bridge” för att en container ska kunna slå upp den andra containerns namn.
En ren ominstallation löste inte nätverksbeteendet
Användaren avinstallerade både Nextcloud och MariaDB, tog bort deras mappar och installerade dem igen från grunden. Samma värdnamnsfel återkom. Detta negativa test är användbart eftersom det visar att problemet inte bara berodde på gamla MariaDB-data eller ett felaktigt lösenord vid ett enda tillfälle.
En varning om lokal åtkomst i Nextcloud var ett separat problem
Användaren hittade ett förslag på nätet om att aktivera allow_local_remote_servers. Att tillämpa den inställningen under den första konfigurationen gjorde att Nextcloud slutade starta korrekt. Gemenskapen förklarade att alternativet gällde en annan säkerhetsregel i Nextcloud och inte löste upplösningen av Docker-namn.
Gemenskapen gick sedan över till direkta tester av Dockers nätverk
Den som svarade bad om följande kontroller:
- om båda containrarna kördes;
- det faktiska nätverksläget som rapporterades av Docker;
- om Nextcloud kunde slå upp eller pinga
mariadb; - MariaDB-containerns aktuella Docker-IP-adress.
Detta är rätt nästa steg efter att konfigurationsskärmbilder inte längre förklarar beteendet: testa anslutningen från samma nätverksnamnrymd som Nextcloud körs i.
Det gick att installera Nextcloud med MariaDB-containerns IP-adress
Det avgörande testet var att ersätta mariadb:3306 tillfälligt med MariaDB-containerns Docker-IP-adress och port. Användaren i källtråden svarade att Nextcloud därefter installerades.
Den som svarade sammanfattade resultatet tydligt:
-
mariadb:3306misslyckades; - den direkta Docker-IP-adressen på port 3306 fungerade omedelbart.
Det är ett starkt bevis på ett problem med upplösning av containernamn.
En direkt container-IP-adress är en giltig diagnostisk tillfällig lösning
Att använda IP-adressen bevisar att databasen kan nås och gör att installationen kan fortsätta. I det aktuella fallet var det en effektiv tillfällig lösning.
Men automatiskt tilldelade container-IP-adresser kan ändras när en container återskapas, tas bort eller ansluts till ett annat nätverk. En lösning som permanent är beroende av 172.17.x.x kan sluta fungera senare utan att någon konfiguration i Nextcloud eller MariaDB ändras.
Ett användardefinierat Docker-nätverk är en bättre långsiktig lösning
Den mer robusta arkitekturen är att ansluta Nextcloud och MariaDB till samma användardefinierade Docker-nätverk och använda ett stabilt tjänste- eller containernamn som databasvärd. Docker tillhandahåller inbäddad DNS i användardefinierade nätverk specifikt för detta ändamål.
Dagens inbyggda YAML-redigering i ZimaOS gör den här typen av nätverksdefinition enklare än när den ursprungliga tråden skapades. Använd den aktuella ZimaOS-modellen för Compose-konfiguration när du bygger ett delat Nextcloud- och MariaDB-nätverk.
Bevara MariaDB-data medvetet
Om MariaDB redan innehåller en fungerande Nextcloud-databas ska du inte radera dess beständiga datakatalog enbart för att ändra Docker-nätverket. Nätverksmedlemskapet kan ändras utan att databasens innehåll återskapas.
Säkerhetskopiera databasen och dokumentera den aktuella användaren, databasnamnet och volymmappningen innan någon migrering.
Inaktivera inte Nextclouds säkerhetskontroller för att reparera Docker-DNS
Inställningar som betrodda domäner, åtkomst till lokala fjärrservrar och konfiguration av omvänd proxy skyddar Nextcloud på HTTP-/applikationslagret. De bör endast ändras när motsvarande Nextcloud-fel kräver det.
A getaddrinfo Felet för databasens värdnamn hör till Docker-nätverkslagret.
Ett bättre diagnosträd
- Bekräfta att MariaDB körs och lyssnar på port 3306.
- Bekräfta att den avsedda databasen finns och att autentiseringsuppgifterna är kända.
- Testa om Nextcloud kan lösa databasens värdnamn.
- Om värdnamnsupplösningen misslyckas kan du testa databascontainerns IP-adress.
- Om IP-adressen fungerar bör du åtgärda Docker-nätverket i stället för att ändra databaslösenord.
- Flytta båda containrarna till ett stabilt användardefinierat nätverk för ett beständigt värdnamn.
Vanliga frågor om Nextcloud och MariaDB
Var det fel på MariaDB?
Nej. Dess logg visade att den var redo att ta emot anslutningar.
Vad betydde meddelandet getaddrinfo for mariadb failed?
Nextcloud kunde inte lösa databasens värdnamn innan den ens nådde autentiseringssteget.
Vad bekräftade diagnosen?
När MariaDB-containerns direkta Docker-IP användes kunde Nextcloud börja installeras.
Bör containerns direkta IP-adress vara den permanenta databasservern?
Det kan fungera, men ett delat användardefinierat Docker-nätverk med stabil namnupplösning är mer robust.
Löste ominstallationen av båda apparna problemet?
Nej. Användaren gjorde en ren ominstallation, och samma fel med värdnamnsupplösningen återkom.
