Hallo zusammen, ich habe einen Shopware 6 Shop von einem Server auf den anderen umgezogen. Soweit hat das auch geklappt. Habe die Einstellungen in der .env bzw. .env.local angepasst. jetzt wollte ich auf die 6.6er updaten aber der Installer scheitert mit der Meldung:
Syntax error or access violation: 1142 ALTER command denied to user ‚flies***_1_w‘@‚78.*****.174‘ for table *******_de.s tate_machine_history
Das ist auch völlig verständlich weil die IP dem alten Server gehört und der neue jetzt einen richigen Hostnamen hat.
Habt ihr eine Idee wo ich die Installationskonfiguration ändern kann? weder die .env noch die .env.local zeigen mir die IP des alten Servers. Hab auch schon die Datenbank und alle Dateiinhalte durchsucht aber nichts finden können.
Liest sich für mich so, dass die Zugangsdaten der neuen Datenbank nicht aktualisiert wurden oder falsch sind. Eventuell mit localhost oder 127.0.0.1 probiert?
Guten Morgen, leider bin ich noch nicht weitergekommen. Egal was ich in die .env oder .env.local eintrage, will erimmer auf den alten server zugreifen.
Auch ein bin/console system:update:finish läuft auf den Fehler:
SQLSTATE[42000]: Syntax error or access violation: 1142 ALTER command denied to user ‚fli--------1_w‘@‚78.—.—.174‘ for table fli--------us_de.state_machine_history
Wie gesagt, der alte Server auf dem der Shop vorher lief lag auf dem Server mit der IP 78...174. Von dort habe ich die Quellcodes, Datenbank etc. auf den neuen Server kopiert, danach die .env und die .env.local so angapasst das
drin steht. Trotzdem versucht das Update oder das system:update:finish auf die IP des alten Servers zuzugreifen und läuft auf die Fehlermeldung
Exception trace:
at /usr/www/users/fliesedv/shop/vendor/doctrine/dbal/src/Driver/PDO/Connection.php:33
PDO->exec() at /usr/www/users/fliesedv/shop/vendor/doctrine/dbal/src/Driver/PDO/Connection.php:33
Doctrine\DBAL\Driver\PDO\Connection->exec() at /usr/www/users/fliesedv/shop/vendor/doctrine/dbal/src/Connection.php:1211
Zieht der Teil in doctrine/dbal die Zugangsdaten noch von einer anderen Stelle als .env oder .env.local?
Was meinst du mit „Die .env hast du nicht als php abgeleitet?“ Ich so etwas nicht aktiv gemacht. Muss ich das nachholen?
EDIT: Nochmal als Nachtrag. Ich hab jetzt ein Backup zurückgeladen damit der Shop wieder läuft. Beim aktualisieren z.B. einer Amazon-Pay- Erweiterung fällt diese ebenfalls auf die NAse mit:
Internal Server Error
An exception occurred while executing a query: SQLSTATE[42000]: Syntax error or access violation: 1142 CREATE command denied to user ‚fli----------w‘@‚78.—.—.174‘ for table f-----------e.swag_amazon_pay_transaction
Hat die Admin-Oberfläche vlt. irgendwo noch eine eigene .env oder .env.local rumliegen?
Definitiv MySQL Zugangsdaten. Es gibt eine env.php bzw env.local.php, wenn du diese über die CLI erstellen lässt. Diese hat mehr Relevanz als die .env.local, wenn ich mich nicht irre.
Schon einmal in der CLI getestet, ob du per mysql -u xyz -p auf die Datenbank Zugreifen kannst mit den Daten?
Es gibt keine andere Stelle, wo die Daten abgelegt werden. So blöd es klingt, aber bist Du ganz sicher, das es aus dem Ordner, in dem Du die Daten änderst, geladen wird? Wenn Du in public eine abc.html (oder irgendein anderer Name, den es normalerweise nicht gibt) mit etwas Text anlegst, wird die geladen? Gibt es im Hauptverzeichnis neben der .env und .env.local eine .env.local.php? Oder eine .env.prod / .env.prod.local / .env.dev / .env.dev.local? Oder nutzt Du Umgebungsvariablen, z.B. in Verbindung mit Docker?
Tut mir leid das ich eure Zeit verschwendet hab. Asche auf mein Haupt! Schwierige Geschichte.
Ich bin bei Hetzner und da liegt der Datenbankserver mit einem Hostnamen auf einem 213er IP-Bereich. Der WWW-Host hat eine 78er IP. Die haben aber eine SSH-Verbindung mit Route vom WWW-Host zum Datenbankserver. Deswegen hat er immer die Fehlermeldung mit der IP des WWW-Host ausgespuckt. Das hat mich verwirrt.
Das eigentliche Problem liegt tatsächlich in den Zugangsdaten. Bei Hetzner gibts einen Root-Benutzer, einen R/W-Benutzer und einen R-Benutzer. Ich hatte den Shop als R/W-Benutzer angelegt und den Dump seinerzeit beim Umzug als Root-Benutzer über den phpmyadmin angelegt.
Der eigentliche Fehler war auch kein „access denied Fehler“ sondern „Syntax error or access violation: 1142 ALTER command denied to user“
weil der R/W-Benutzer kein ALTER in der SQL-DB ausführen darf.
Da im Betrieb nur R/W notwendig sind, ists mir bisher nicht aufgefallen. Jetzt nachdem der Shop als root zugreifen darf, klappt auch das Update.
