Zbrain aufsetzen probleme
| 🔧 Z-Brain: Aufbau-Probleme | |
|---|---|
|
Datei:Symbol support vote.svg | |
| Übersicht | |
| Docker-Volumes neu erzeugt | Docker |
| Logo nicht sichtbar | MediaWiki |
| 502 Bad Gateway | NPM |
| LocalSettings.php verloren | MediaWiki |
| Stand: Juni 2026 | |
Hier dokumentiere ich, welche Probleme beim Aufsetzen von Z-Brain (diesem Wiki) aufgetaucht sind und wie ich sie gelöst habe — gut zum Nachschlagen, falls der gleiche Mist später wieder auftaucht.
Docker Compose erzeugt neue, leere Volumes statt alte wiederzuverwenden
Komponente: Docker
Beim Verschieben/Umbenennen eines Compose-Projekt-Ordners (z.B. mediawiki-test → zbrain) leitet Docker Compose den Volume-Namen standardmäßig vom Ordnernamen ab. Folge: beim nächsten docker compose up legt Docker neue, leere Volumes mit dem neuen Präfix an, statt die alten (mit den echten Daten) weiterzuverwenden — die App startet dann scheinbar normal, aber komplett leer bzw. zeigt den Erstinstallations-Assistenten erneut.
Lösung: In der docker-compose.yml die betroffenen Volumes explizit auf ihren festen, alten Namen fixieren, damit Docker sie wiederfindet statt neue anzulegen:
volumes:
mediawiki-db-data:
name: mediawiki-test_mediawiki-db-data
external: true
Vorher prüfen mit docker volume ls | grep <projektname> — wenn zwei Sätze ähnlich benannter Volumes auftauchen (altes + neues Präfix), ist das die Bestätigung für dieses Problem.
MediaWiki Vector-2022 zeigt das Logo nicht, ohne icon-Key in $wgLogos
Komponente: MediaWiki
$wgLogos mit nur 1x/2x-Einträgen reicht bei der Skin Vector-2022 nicht aus — ohne zusätzlichen icon-Schlüssel fällt die Skin auf den reinen Text-Wortmark zurück, das Logo-Bild bleibt unsichtbar (auch wenn die Bilddatei selbst korrekt liegt und per curl erreichbar ist).
Lösung: Den icon-Eintrag ergänzen:
$wgLogos = [
'1x' => "$wgResourceBasePath/resources/assets/zbrain/logo.png",
'2x' => "$wgResourceBasePath/resources/assets/zbrain/logo-2x.png",
'icon' => "$wgResourceBasePath/resources/assets/zbrain/logo.png",
];
Änderung greift sofort nach docker cp der angepassten LocalSettings.php in den Container, kein Neustart nötig.
NPM 502 Bad Gateway durch fehlende Docker-Netzwerk-Verbindung
Komponente: Nginx Proxy Manager
Läuft Nginx Proxy Manager selbst containerisiert (z.B. als npm-app-1), bedeutet localhost im Forward-Host-Feld den NPM-Container selbst, nicht den Host-Server. Trägt man dort die Host-IP oder localhost ein, während das Ziel in einem anderen, isolierten Docker-Netzwerk läuft, kommt openresty mit 502 Bad Gateway zurück.
Diagnose: Netzwerke beider Container vergleichen:
docker inspect npm-app-1 --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}}{{end}}'
docker inspect <zielcontainer> --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}}{{end}}'
Lösung: Zielcontainer zusätzlich ins NPM-Netzwerk hängen (rein additiv, bestehende Netzwerk-Zugehörigkeit bleibt erhalten):
docker network connect npm_default <zielcontainer>
In NPM dann als Forward-Host den Container-Namen eintragen (z.B. mediawiki) statt einer IP, und als Port den internen Container-Port (z.B. 80), nicht den extern weitergeleiteten Host-Port (z.B. 8081).
Hinweis: Diese Netzwerk-Verbindung ist nicht in der docker-compose.yml hinterlegt — bei einem künftigen docker compose down/up des Zielcontainers muss der connect-Befehl ggf. erneut ausgeführt werden, sofern er nicht dauerhaft in die Compose-Datei aufgenommen wird.
MediaWiki-Container verliert LocalSettings.php bei falschem Volume-Mount
Komponente: MediaWiki
Im offiziellen mediawiki-Docker-Image landet die vom Setup-Assistenten erzeugte LocalSettings.php direkt unter /var/www/html/LocalSettings.php — nicht unter /var/www/html/config/. Wird nur Letzteres als Volume gemountet, geht die Konfigurationsdatei beim nächsten Container-Neuaufbau verloren (während Datenbank- und Bilder-Volumes unberührt bleiben, da diese korrekt gemountet sind).
Lösung für zukünftige Setups: Entweder direkt /var/www/html/LocalSettings.php als einzelne Datei mounten, oder nach jedem Setup-Lauf eine Sicherungskopie außerhalb des Containers aufbewahren:
docker cp mediawiki:/var/www/html/LocalSettings.php ~/mediawiki-LocalSettings-backup.php
Falls schon verloren: Nicht in Panik geraten — die Wiki-Inhalte liegen in der Datenbank, nicht in dieser Datei. Datenbank-Zugangsdaten (Host, Name, Nutzer, Passwort) lassen sich aus der docker-compose.yml rekonstruieren und die Datei von Hand neu schreiben, ohne den Setup-Assistenten erneut durchlaufen zu müssen.