GELÖST-Slim Application Error - Could not connect to database - NACH Datenbank-Import

Shopware 5 Installation/Einstieg
1

Hey,

ich habe diesen Fehler bereits mit dem RC von 5.2 gehabt, nun erscheint er in der stable wieder. Ich möchte jedoch gerne Shopware 5.2 mit PHP 7.0.x nutzen.

Der Fehler erscheint direkt im Anschluß an die erfolgreiche Installation, das heißt in dem Schritt in dem man sich eigentlich im Backend anmeldet. Das heißt die Datenbank ist befüllt und startbereit.

Der Fehler besagt dann aber:

Slim Application Error

The application could not run because of the following error:

Details

Type: RuntimeException
Code: 1045
Message: Could not connect to database. Message from SQL Server: SQLSTATE[HY000] [1045] Access denied for user ' ******'@'localhost' (using password: YES)

Die Installation liegt auf einem Uberspace mit Maria DB (MySQL 5.5.5) und PHP 7.0.3. Die MariaDB-Lösung ist bei Uberspace folgendermaßen gelöst:

MariaDB 10.0

Wir setzen bei uns die jeweils zur Distribution gehörige MySQL-Version ein, was bei CentOS 6 derzeit die Version 5.1 ist. Unsere künftigen Hosts auf Basis von CentOS 7 werden das zu MySQL 5.5 kompatible MariaDB 10.0 enthalten.

Für den Moment können wir dir eine Übergangslösung anbieten. Wir betreiben einen Standalone-Host mit MariaDB 10.0, auf dem wir für einzelne User, die das heute schon benötigen, Datenbanken anlegen, auf die dann über einen separaten Port (technisch gesehen über einen SSH-Tunnel) zugegriffen werden kann. Hierbei gibt es aber zwei wichtige Dinge zu beachten:

Wir erstellen zwar auch von diesem separaten Host regelmäßig Backups; auf jene hast du aber - im Gegensatz zu den normalen MySQL-Backups - nicht direkt Zugriff, sondern wir müssen dir Dumps auf Anfrage bereitstellen.

Es handelt sich wie gesagt um eine Übergangslösung, die nur für Leute gedacht ist, die zwingend hier und jetzt unbedingt MySQL 5.5 bzw. etwas dazu Kompatibles brauchen. Sobald unsere CentOS-7-Hosts am Start sind, gibt es noch eine Übergangsfrist von voraussichtlich 3 Monaten, innerhalb derer die betreffenden User dann von ihrem CentOS-6- auf einen CentOS-7-Host migrieren müssen, wo MariaDB dann offizielles Feature ist.

Mit dem Befehl uberspace-setup-mariadb kannst du dir eine Datenbank auf dem Host anlegen. Die Zugangsdaten werden in ~/.my.mariadb.cnf abgelegt.

Hostname: 127.0.0.1 (nicht „localhost“; damit würde der lokale Socket verwendet und der Port ignoriert)

Port: 3307 (statt des Default-Ports 3306)

Auf der Shell würdest du also z.B. mysql -h 127.0.0.1 -P 3307 --password bzw. mysql --defaults-file=~/.my.mariadb.cnf eingeben können, um dich mit dem MariaDB-Server statt mit dem lokalen MySQL-Server zu verbinden.

Kann jemand das Problem nachvollziehen oder hat es vielleicht auch? Der Support von uberspace geht von einem Bug in Shopware aus.

Möglicherweise müsste in Access denied for user ‚******‘@‚localhost‘ statt localhost die IP 127.0.0.1 stehen.

In der Hoffnung auf Hilfe verbleibe ich mit herzlichem Gruß

Manu

2

Da gibt es keinen Bug in Shopware.

Deine Zugangsdaten sind falsch einegegeben oder die Datenbank / bzw. Datenbank-Benutzer sind falsch konfiguriert.

Die Meldung kommt ja vom Datenbankserver.

EDIT:

hmm… hier https://forum.shopware.com/discussion/38559/datenbankanbindung-slim-fehler-nach-update-auf-5-21#latest hat noch jemand das Problem.

Vl. habt ihr gemeinsamkeiten im Setup?

1 „Gefällt mir“
3

Hallo,

ich hänge an genau der gleichen Stelle fest.

Wo genau können die Werte für die Datenbank über das Dateisystem eingegeben werden?

In der html/config.php stehen die korrekten Werte auf jeden Fall drin.

Die „falschen“ Default Werte in der html/engine/Shopware/Configs/Default.php habe ich abgeändert und den port hinzugefügt.

Wo bekommt die /var/www/virtual/wo/html/engine/Shopware/Components/DependencyInjection/Bridge/Db.php Ihre Daten her?

 

4

Da  gibt  es einen Bug in Shopware.
Auch „hier“ haben wir wieder einen abweichenden Port - hatten wir im Forum schon mit 5.2  Wearing-Sunglasses
https://forum.shopware.com/discussion/comment/164681/#Comment_164681
Shopware Issuetracker

3 „Gefällt mir“
5

Die Lösung steht auch schon in den kommentaren des Tickets. Die Angabe von „localhost“ ignoriert die Angabe des Ports - also mit IP-Adresse arbeiten.

6

Ja, Spitze, tolle Community! Top, danke! Nächstes Mal schau ich mir den Issuetracker mal genauer an!

Lieber Gruß

Manu

7

Hallo,

ich habe hier das gleiche Problem (zum Glück auf einer Testumgebung… ;)) - nach dem Update werde ich auf /recovery/update/index.php/done geleitet, danach geht es nicht mehr weiter mit

Could not connect to database. Message from SQL Server: SQLSTATE[28000] [1045] Access denied for user ' ******'@'localhost' (using password: YES)

In der config.php ist der Port auch korrekt eingetragen, 5.1.x lief damit ohne Probleme. Der Workaround mit der Portangabe funktioniert hier nicht und wird mit

Could not connect to database. Message from SQL Server: SQLSTATE[HY000] [2005] Unknown MySQL server host '127.0.0.1:3309' (1)

quittiert. Die config.php sah hier so aus:

  array (
    'username' => '***',
    'password' => '***',
    'host' => '127.0.0.1:3309',
    'port' => '3309',
    'dbname' => '***,
  ),
 'front' => array( 'showException' => true )
);

 Auch das löschen der Zeile “‘port’ => ‘3309’,” hat nichts verändert. Hat jemand ne Idee wo man noch ansetzen könnte?

8

Hallo,

nimm lieber mal den Port bei Host weg. Das ist ja so doppelt.

9

Ja, bei der Config hatte ich versucht, den Port über die IP-Adresse zu definieren, wie hier beschrieben:

Ursprünglich sah sie so aus:

  array (
    'username' => '***',
    'password' => '***',
    'host' => '127.0.0.1',
    'port' => '3309',
    'dbname' => '***,
  ),
 'front' => array( 'showException' => true )
);

Damit lief auch 5.1 ohne Probleme, das Update auf 5.2 bis zum Punkt nach „Aufräumen“.

 

Edit: Es lag an /engine/Shopware/Components/DependencyInjection/Bridge/Db.php. Dort gab es in der Funktion buildConnectionString folgenden Eintrag doppelt:

 if (!empty($dbConfig['socket'])) {
            $connectionSettings[] = 'unix_socket=' . $dbConfig['socket'];
        }

Einen davon umändern in

if (!empty($dbConfig['port'])) {
            $connectionSettings[] = 'port=' . $dbConfig['port'];
        }

und das Update lief durch.

10

Das Setzen des Ports direkt hinter die IP hat bei mir leider auch nicht funktioniert.

Bringt die Änderung in meinem Fall im Nachhinein noch was? Ich kann den Update Prozess ja nicht neu starten weil ich im Wartungsmodus gefangen bin.

11

Ja, das sollte funktionieren (zumindest hat es das bei mir). Nach der Änderung dann $shopwareurl/recovery/update/index.php/done aufrufen und das Update ist durchgelaufen. Allerdings habe ich jetzt nen 503er, egal ob Backend oder Frontend. Ob es irgendwie mit dem Fehler hier zusammengängt, weiß ich nicht.

 

12

Einen 5.21 Shop mt weiteren 503 Fehlern wollte ich vermeiden. Deshalb habe ch jetzt 5.1x wiederhergestellt und bleibe vorerst dabei. Andere Hinweise haben bei mir leider nicht zum Erfolg geführt.