Neueinrichtung: Kein Kontakt zur Datenbank

Moin,

ich versuche Nextcloud in Docker zum Laufen zu bekommen. Jedoch bekomme ich bei der Angabe der Datenbank immer eine Fehlermeldung:

Fehler
Error while trying to create admin user: Failed to connect to the database: An exception occurred in driver: SQLSTATE[HY000] [2002] No such file or directory

Ich richte mit folgendem Docker-Befehl eine MariaDB ein:

MariaDB

docker run \
-e MYSQL_USER=nextcloud \
-e MYSQL_PASSWORD=jake-venomous-smoke \
-e MYSQL_ROOT_PASSWORD=TestPasswort \
-e MYSQL_DATABASE=nextcloud_db \
--name nextcloud_MariaDB \
-v ~/docker/nextcloud_MariaDB:/var/lib/mysql \
-p 8085:8080 \
--restart always \
-d mariadb:latest

Hiermit erstelle ich einen Nextcloud-Container und gebe die Datenbankinformationen vor:

Nextcloud

docker run -d \
-p 8080:80 \
-v /Users/gerhard/docker/nextcloud-data:/var/www/html \
-e NEXTCLOUD_ADMIN_USER=admin \
-e NEXTCLOUD_ADMIN_PASSWORD= TestPasswort \
-e MYSQL_DATABASE=nextcloud_db \
-e MYSQL_USER=nextcloud \
-e MYSQL_PASSWORD= TestPasswort \
-e MYSQL_HOST=localhost:8085 \
--name "nextcloud_persistent" \
--restart always \
nextcloud

Trotz korrekter Angaben (also ich denke, dass sie korrekt sein müssten) funktioniert es nicht.

Wo ist denn das Problem? Was habe ich falsch gemacht?

Ich habe außerdem auch versucht statt localhost:8085 auch http://localhost:8085 oder 0.0.0.0:8085, 10.0.1.140:8085, http://10.0.1.140:8085 usw. Ich habe alle Spielweisen des Hosts durch. Nichts funktioniert.

Vor jedem erneuten Versuch lösche ich auch die Daten in ~/docker/, damit ich jungfräulich beginnen kann. Sie werden auch immer wieder normal angelegt. Mit der eingebauten SQLite funktioniert es auch, nur nicht mit der MariaDB und auch nicht mit PostgreSQL.

im container ist localhost der container selber. jeder container hat einen eigenen namen und ip adresse.

da docker sein eigenes dns mitbringt, ist das der server name.

kannst du weglassen. beide container sprechen über das interne docker netzwerk. und die db soll nicht von außen erreichbar sein.

btw: 8080 ist nicht der default port von mysql.

8080 ist nicht der default port von mysql.

Das hatte ich von der Docker-Seite von MariaDB. Aber aufgrund Deiner Aussage habe ich noch mal nachgesehen und sehe, dass ich mich vertan habe. Das ist der Port für adminer.
https://hub.docker.com/_/mariadb
Danke für den Hinweis! :slight_smile:

da docker sein eigenes dns mitbringt, ist das der server name.

Das ist bei mir der Name des Containers in Docker.

im container ist localhost der container selber. jeder container hat einen eigenen namen und ip adresse.

Also muss das so lauten, wenn ich nicht die interne IP-Adresse von Docker verwenden will?
-e MYSQL_HOST=nextcloud_MariaDB.local:3306

Ich probiere das alles gleich mal aus. Vielen Dank! :slight_smile:

den port kann man auch weglassen, wenn es sich um den default port handelt. :wink:

den port kann man auch weglassen, wenn es sich um den default port handelt.

Auf der Einrichtingsseite von Nextcloud steht, dass man den Port unbedingt mit angeben muss. Deswegen hatte ich ihn mit angegeben.

nextcloud_MariaDB.local:3306 funktioniert übrigens auf der Einrichtungsseite von Nextcloud nicht, ich muss die IP-Adresse nehmen. Mit der IP-Adresse (und alles andere manuell eingegeben) funktioniert das nun. :slight_smile:

Nun muss ich die Daten nur noch per Containererstellung vor-ausfüllen, also so wie ursprünglich gedacht. Das hatte eben noch nicht funktioniert. Irgendwo ist da noch der Wurm drin. Außerdem muss ich noch den Container per Namen ansprechen können statt per IP-Adresse. Denn letztere könnte sich ändern (oder ich muss eine feste Adresse vorgeben).

-e MYSQL_HOST=172.17.0.5:3306 funktioniert inzwischen prima. :slight_smile: Allerdings würde ich gerne den Container per Namen ansprechen. Und das bekomme ich leider noch nicht hin.

der container ist ja auch nicht in der domain .local. der lebt in seiner eigenen welt. :wink: ansonsten mit sudo docker psmal schauen, was docker glaubt, wie der container heißt.

du bist sicher, dass das geht? ich mach das immer mit

auf der commando zeile. (in den {{ }} stehen variablen, da musst du bei dir die richtigen werte einsetzen.)

Moin,

da hat @Reiner_Nippes ja schon gute Hilfestellung gegeben.

@Uhlhorn Ich möchte, nach kurzem Überfliegen des obigen Anliegens, nur die Frage aufwerfen, warum es denn eigentlich Docker sein muss? Beim Heimeinsatz wäre doch eine ganz banale Installierung und dabei Nutzung von MariaDB oder PostgreSQL zusammen auf einem System-Server m.E. viel zielführender.
:smirk:

Oder ist der Server bei einem Host-Provider angesiedelt?

Docker und andere Konzepte lohnen sich natürlich bei einem Host-Provider oder wenn man selbst viele verschiedene System warten muss (oder einfach mal nur ausprobieren möchte), aber man sollte den Zusatzaufwand durch die Paketverwaltung und andere Probleme nicht unterschätzen. Keep it simple.
:smile:

immer.

Juppp. Deshalb Docker. Vergleiche mal meine beiden Playbooks.

Blech: https://github.com/ReinerNippes/nextcloud/tree/nextcloud-reloaded
Und Docker: GitHub - ReinerNippes/nextcloud_on_docker: Run Nextcloud in Docker Container on various Linux Hosts

Die Docker Variante ist in allen belangen deutlich einfacher.

Schöne Arbeit und ein sehr guter Beitrag.
:+1:

Trotzdem wage ich vorsichtig zu widersprechen und verwalte bislang weiter die allermeisten VMs ganz ohne Docker und jeweils als Debian Grundinstallation. Die einzige Art von VM, die immer mal wieder Zicken macht und wegen des (zumindest meiner – vielleicht inzwischen irrigen ? – Ansicht nach) anscheinend ungelösten Problems des Speicherhungers bei wiederholten Docker-Installierungen gelöscht werden muss, ist eine Ubuntu-VM mit Collabora-Docker-Image, weil ich bislang immer noch zu faul zur Selbstinstallierung auf Debian aus den Quellen von Collabora CODE war.
:lab_coat:

Bleibt mit Blick auf die o.g. Playbook-Pakete noch zu erwähnen, daß ich mich aus gutem Grund für Apache 2.4.x ohne php-fpm entschieden habe und deshalb den (für manche Anwendungsprofile) natürlich sehr interessanten NGINX bis auf Weiteres links liegen lasse. Das mag alles durchaus sinnvoll zusammengesetzt sein, ich aber koche nunmal eine andere Suppe, wofür ich hier um ein entsprechendes Verständnis bitte.
:smirk:

Mit einem guten Werkzeug wie proxmox VE hat man es natürlich auch einfacher.
:smiley:


@Uhlhorn und andere lesende Personen bitte ich vielmals um Entschuldigung für meine Abschweifungen und wünsche viel Erfolg für die eigentliche Problemlösung zusammen mit Docker und @Reiner_Nippes , der sich ganz offensichtlich damit auskennt und anscheinend wirklich weiß, wovon er schreibt. So sollte es ja auch sein, denke ich.
:pray: :+1:


Ich möchte ganz unmissverständlich nochmals gerne unterstreichen: Die beiden Playbooks sind eine tolle Arbeit und ein super Angebot. Ich wünsche viel Erfolg mit Docker und anderen Experimenten.
:four_leaf_clover:

Im Übrigen aber pfeife ich ohne bösen Hintersinn mein Liedchen und mache, wie es mir gefällt.
:innocent:

der container ist ja auch nicht in der domain .local . der lebt in seiner eigenen welt. :wink:ansonsten mit sudo docker ps mal schauen, was docker glaubt, wie der container heißt.

Der heißt so, ich verwende auch Portainer, da habe ich immer alles schön übersichtlich. Trotzdem mache ich das Meiste per Terminal.

Oh, Moment … ich muss mal weg … Ich melde mich später.

Ja, bin ich. Hier ist mein aktueller Stand:
(Ich habe die Zeilen am Ende mit Leerzeichen Backslash umbrochen, damit man es besser lesen kann.)

MariaDB

docker run \
-e MYSQL_USER=nextcloud \
-e MYSQL_PASSWORD= TestPasswort \
-e MYSQL_ROOT_PASSWORD=TestPasswort \
-e MYSQL_DATABASE=nextcloud_db \
--name nextcloud_MariaDB \
-v ~/docker/nextcloud_MariaDB:/var/lib/mysql \
--restart always \
-d mariadb:latest

Hier wird also der DB-Username, dessen Passwort, das Root-Passwort und der Datenbankname mit übergeben. Außerdem werden die Daten beim Mac in den Benutzerordner unter ~/docker/nextcloud_MariaDB/ abgelegt.

Nextcloud

docker run -d \
-p 8080:80 \
-v ~/docker/nextcloud-data:/var/www/html \
-e NEXTCLOUD_ADMIN_USER=admin \
-e NEXTCLOUD_ADMIN_PASSWORD=TestPasswort \
-e MYSQL_DATABASE=nextcloud_db \
-e MYSQL_USER=nextcloud \
-e MYSQL_PASSWORD=TestPasswort \
-e MYSQL_HOST=172.17.0.5:3306 \
-e NEXTCLOUD_TRUSTED_DOMAINS=0.0.0.0 \
--name "nextcloud_persistent" \
--restart always \
nextcloud

Bei der Nextcloud werden alle hinter -e angegebenen Daten vorausgefüllt.
Auch hier werden die Daten im Userordner von macOS abgelegt.

Aber das Ganze funktioniert jetzt so wie hier gezeigt. Nur dei MYSQL_HOST würde ich gerne einen Namen, eine Domain oder so etwas eintragen, denn die IP-Adresse ist ja nicht immer 172.17.0.5.

Weil Docker überall einheitlich ist. Wenn ich irgendwo hin komme, ist es egal, was derjenige laufen hat. Mit Docker und 2 Befehlen kann ich jetzt so eine Software einrichten. Und man muss sich keine Sorgen um Abhängigkeiten machen.

Nun ja, mit Blick auf die, mit den hinter den erkennbaren, elektronischen Identitäten anzunehmenden Personen (anscheinend ganz unmittelbar aber völlig zulässiger Weise) hier verbundenen, Rieger ICT services und die dort zu vermutenden Bestrebungen natürlich ein sehr valides Argument.

Mit einem Dockerlein viele Serverlein stabil halten und dabei den Chef und die Kunden glücklich machen, ist nicht das schlechteste Ziel.
:four_leaf_clover:

Wie schon gesagt, ein valider Ansatz, aber eben nicht alternativlos.
:innocent:

@Uhlhorn: ich wollte auf folgendes hinweisen.

:~$ docker exec -u www-data nextcloud ping nextcloud-db
ping: permission denied (are you root?)
PING nextcloud-db (172.17.0.5): 56 data bytes
:~$ docker exec -u www-data nextcloud ping nextcloud-db.local
ping: bad address 'nextcloud-db.local'

geht bei dir ein docker exec ... ping nextcloud_MariaDB.local d.h. wird die adresse aufgelöst?

@TP75 die gute jess lässt (wohl auf ihrem mac) alles im container laufen.
vorteil: a) cleanall und dein system ist wieder sauber. b) neues macbook -> git clone … und alle apps sind wieder da.


in ihren .dotfiles hat sie alle gängigen cli commands durch docker run ersetzt

deshalb finde ich docker so sexy. und wenn man software von lieferanten einbinden muss, umsomehr. (never again: runs on ma maschine)

@Reiner_Nippes Danke und ein interessanter Ansatz. Für entwicklungslastige Power-User (und solche, die es werden wollen) sicherlich eine tolle Sache.
:partying_face:

Als Anwender in einer verteilten, gemischten Systemumgebung mit von ehemals Mac OS X Server (damals voll ausgebaut) und jetzt macOS Server (leider zunehmend reduziert) über den sog. Profil-Manager verwalteten, zahlreichen Mac-Rechnern und von anderen Un*x-Systemen umgeben, kann ich den Docker-Ansatz und OpenStack etc. zwar durchaus nachvollziehen, sehe aber vorerst überhaupt keine Notwendigkeit, noch eine Zwischenebene einzuziehen.
:cowboy_hat_face:

Insofern ist Nextcloud natürlich eine sehr willkommene Ergänzung, solange man dahinter eine stabile und weitgehend ausfallsichere Server-Umgebung sowie tatsächlich funktionierende Datensicherung bereitgestellt wissen kann. Es lassen sich damit bereits viele lustige und auch durchaus sehr ernstzunehmende Sachen anstellen, ohne daß man (welchen gerade angesagten Container-Manager auch immer) noch dazupacken müsste.
:slightly_smiling_face:

Es sollte die geneigte lesende und technisch etwas breiter interessierte Person nicht unbedingt wundern, wenn ich als offen bekennender Debian Befürworter auch sonst den Grundsatz verfolge, daß Stabilität durch gesenkte Komplexität und Vermeidung von vermeidbarem Durcheinander möglich sein sollte. Daß muss dem technischen Fortschritt und dem eigenen Fortkommen nicht unbedingt schaden und vermeidet teilweise sogar unnötige Duplizitäten als möglichen Angriffsvektor auf ansonsten monoton monolitische Systemumgebungen.
:lab_coat:

Siehe dazu (hier im User-Forum nötiger Weise ganz unverbindlich) z.B. auch:

Nicht nur aber vor allem auch für eine Produktivumgebung bedeutet das oft genug nunmal auch, sowohl lieber die Kirche im eigenen Dorf zu lassen als auch lieber den Spatz in der eigenen Hand zu haben als die Taube auf dem fremden Dach zu suchen.
:safety_vest:

Das soll interessante neue Ansätze und agiles Vorgehen in entsprechend flexiblen aber gleichfalls anspruchsvollen Systemumgebungen selbstverständlich nicht ausschließen. Vielen Dank für die guten Anregungen.
:grin:

Viel Erfolg.
:four_leaf_clover:

Ich habe nichts anderes behauptet. :wink:

Nein, ping steht nicht zur Verfügung.
OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"ping\": executable file not found in $PATH": unknown
(Ah, man muss den Text in Akzents einfassen, damit er so dargestellt wird. :slight_smile: Typografisch ein bisschen blöde, aber was soll’s. Ich habe meine Posings für eine bessere Lesbarkeit geändert.)

@ TP75 Gerade weil MacOS Server jetzt so beschnitten wurde, brauchen wir Ersatz dafür, also für die nun fehlenden Dienste. Infrage kommen eine Synology Disk Station oder ein Linux-Rechner. Das alles erkunde ich gerade. Das benötige ich für mich (selbständig, SOHO) und für die Betriebe meiner Familie. Wir arbeiten alle komplett auf Macs. (Okay, ich betreibe auch noch einen GPU-Server unter Windows.)

Stimmt. :+1: War ja auch nur ein peinlicher Adressierungfehler bei meiner Benutzung der machnchmal recht dusseligen Zitatfunktion in diesem Forum. Gemeint als eigentlicher Adressat war der andere Autor und in solch einem offenen Forum sind solche Fragen aber ohnhing ziemlich müßig. Alle lesen, manche schreiben mit, zuviele wissen nicht worum es eigentlich gerade geht, und wir alle verlieren manchmal den Faden. :smirk:

Ja durchaus, kann man so machen.
:rocket:

Oder man portiert mit Hilfe von MacPorts ausreichend viele Dienste aus der Un*x FOSS-Landschaft auf das alte Mac-Eisen, was als damit wiederbelebter Server noch gute Dienste erweisen kann. Dazu noch einen Virtualisierer und lustige VMs mit anderen Betriebssystem laufen lassen. Dann kann man auch solche Kisten wie die Drobo-Boxen nehmen (Thunderbolt, nicht USB oder Gbit) und deren logische Ausfallsicherheit und vor allem Austauschbarkeit der Datenträger zwischen den Boxen bei deren Hardware-Ausfall nutzen.
:lab_coat:
Aus grundsätzlichen Erwägungen heraus würde ich dringend mehr als eine solche Daten-Station und bitte an physikalisch getrennten Orten empfehlen.
:safety_vest:

Hört sicher aber schon ganz gut an. Viel Spaß und guten Erfolg damit.
:smiley:

So, ich habe jetzt ausgetüftelt, wie man einen Container per Namen erreicht:

Netzwerk erstellen

docker network create NextcloudNetwork
docker network connect NextcloudNetwork nextcloud_MariaDB
docker network connect NextcloudNetwork nextcloud_persistent

Netzwerk überprüfen

docker network inspect NextcloudNetwork

Das Problem daran ist nur, dass ich erst nach Erstellung des Containers ein Container mit dem Namen habe. Ich kann also erst das Netzwerk erstellen, nachdem ich die Container erstellt habe.

Hmm … mal überlegen …

Also, wenn ich mir das recht überlege, erstelle ich erst den Container nextcloud_MariaDB.
Dann erstelle ich das Netzwerk mit diesem ersten Container:

docker network create NextcloudNetwork
docker network connect NextcloudNetwork nextcloud_MariaDB

Erst jetzt erstelle ich den Nextcloud-Container nextcloud_persistent. Danach kann ich den Container nextcloud_persistent dem Netzwerk hinzufügen.

docker network connect NextcloudNetwork nextcloud_persistent

Jetzt erst starte ich den Nextcloud-Einrichtungsassistenten. Das müsste eigentlich funktionieren …


OT:

Oder ein Cloud-Backup einrichten. :wink:
Klar, ein RAID alleine reicht nicht. Denn bei Feuer, Einbruch, Wasserschaden usw. sind die Daten dann auch weg.

Bei mir selbst sichere ich Die Daten auf ein Drobo, der in einem anderen Raum steht und zusätzlich auf zwei lokale Festplatten am Rechner. Darüber hinaus mache ich noch ein Cloud-Backup (Backblaze) und lagere meine Jobdaten¹ im Dropbox-Ordner. So habe ich eine ganze Reihe von Backups.

Der Charme eines Cloudordners ist, dass von den Dateien immer sofort ein Backup außer Haus gemacht wird. :wink:

Drobo ist klasse, ich habe hier mehrere stehen. Jedoch ist deren Kundendienst extrem kundenfeindlich! Die kann ich inzwischen nicht mehr empfehlen, ich muss sogar davor warnen! Leider gibt es nichts Vergleichbares auf dem Markt.

Was mir passierte:
Eines Tages startete mein Drobo nicht mehr. Ich fragte in deren Forum, ob das an der eingebauten Batterie liegen könnte. Daraufhin wurde mein Beitrag und ich ohne Angabe von Gründen gesperrt.

Eine E-Mail-Anfrage an den Support, warum der Beitrag gesperrt worden sei und ob das Nicht-Starten an der Batterie liegen könnte, wurden beide nicht beantwortet. Ich wurde nach einigen Monaten entsperrt, mein Beitrag jedoch bis heute nicht. :frowning:

Seitdem warne ich vor der Benutzung dieser Geräte und kaufe sie selbst auch nicht mehr. Leider.

(Oh, ich habe eben zufällig entdeckt, dass man auch Linien ziehen kann. :slight_smile: Gibt es irgendwo eine Anleitung für die Steuerzeichen hier?)


¹ Meine Jobdaten unterliegen keiner Geheimhaltung, denn ich mache Daten für Werbung (Bildbearbeitung, Rendering, Animation usw.), die sowieso veröffentlicht werden. Wäre es anders, würde ich natürlich eine Cloudverschlüsselung verwenden.

Das mit den schlechten Erfahrungen tut mir leid. Weiter kann ich nichts beitragen.
:neutral_face:


Mit eigener Elektronik-Werkstatt ausgestattet, haben wir von Anfang an bewusst auf den Kundendienst verzichtet und reparieren selbst oder tauschen entsprechend gegen ein neues Leergerät aus. Aber wir reparieren ja auch mal eine USV selbst, womit normale Anwender und betriebliche Kunden schnell überfordert sein dürften.
:lab_coat:
Darf man also bitte nicht vergleichen.
:cowboy_hat_face:


Die Syntax hier im Forum ist anscheinend mit Markdown wie bei GitHub vergleichbar.

Eine deutschsprachige Einführung zu Markdown ist ganz allgemein verfügbar.

Hoffe es hilft.
:smile:

1 Like

Oh ja, danke sehr. :slight_smile:

Das mit dem Drobo ist echt schade, denn es sind eigentlich gute Geräte.

1 Like