Nextcloud Passwörter nach Migration falsch

  • Ich habe den Webhosting 8000 Tarif und versuche meine bisher lokal betriebene Nextcloud dort unterzubringen. Dazu habe ich auf dem Server die Cloud angehalten (maintenance mode), die Daten in ein Tar-Archiv gepackt, Nextcloud ebenso, einen MySQL-Dump gemacht und alles rüberkopiert und entsprechend entpackt.

    Leider funktionieren danach die User Passwörter nicht mehr. Setze ich ein Passwort über die Vergessen-Funktion zurück, klappt alles und ich komme in den Account. Das ist natürlich keine Option für die anderen Benutzer.


    Hat jemand eine Idee?

    Webhosting 8000, mehrere Wollmilchsäue

  • Wird beim dump der Zeichensatz der Datenbank mit übertragen? Wenn nicht, dann könnte es sein, das die gehashten Passwörter irgendwelche kryptischen Zeichen enthalten, die unter einem anderen Zeichensatz nicht "verfügbar" sind... Oder der dump ist einfach nur fehlerhaft, wieso auch immer

  • Ja, der Zeichensatz (utf8mb4) wird mitübertragen und auch in die neue DB übernommen.

    Ich hab jetzt zum Testen mal nur die oc_users Tabelle per phpMyAdmin exportiert und wieder importiert, aber das half auch nichts.


    Hat noch jemand eine Idee?

    Webhosting 8000, mehrere Wollmilchsäue

  • Ich habe auf die Art schonmal eine Nextcloud Instanz umgezogen, das lief problemlos. Ich hatte aber auch exakt die gleiche Konfiguration des Datenbank (auch gleiche MariaDB version). Ich weiß nicht, wie das bei dir aussieht? Ich kann mir eigentlich nur ein Datenbankproblem vorstellen (oder du hast einen neuen Salt ("passwordsalt") oder Instanceid in der Konfigdatei von Nextcloud ;))


    Btw.: Beim Kopieren der Nutzerdaten darauf achten, dass sich der Timestamp nicht ändert, sonst laden alle clients die Daten erneut runter. (rsync mit -t)

  • Verwendest Du dieselbe PHP-Version am alten wie neuen Server?


    Ich habe den Effekt mit den falschen Passwörtern auch beobachten können. In einer Testinstallation tritt das Problem in dem Moment auf wenn ich PHP von 7.3 auf 7.1 setze. Habe aber nicht weiter untersucht ob da etwa ein Modul fehlt oder ein anderes Problem vorliegt?


    v.

  • (rsync mit -t)

    rsync geht leider nicht, da das in dem Webhosting 8000 Tarif nicht enthalten ist. Die Zeitstempel sind aber über das tar Archiv erhalten geblieben.

    Verwendest Du dieselbe PHP-Version am alten wie neuen Server?

    Fast: am Server war es 7.2.20, im Hosting ist es 7.2.19


    Bei der Datenbank gibt es noch einen kleinen Unterschied: Alt war es

    mysql Ver 15.1 Distrib 10.1.38-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

    im Hosting ist es

    mysql Ver 15.1 Distrib 10.0.38-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2


    Bei den kleinen Unterschieden kann ich mehr schwer vorstellen, dass diese verantwortlich sein sollen.

    Webhosting 8000, mehrere Wollmilchsäue

  • kannst du mal ein Passworthash aus der alten Datenbank mit der neuen Datenbank vergleichen? Also einmal direkt nach dem importieren, einmal nach dem Passwort zurücksetzen und wieder auf das gleiche setzen. Hast du exakt die gleiche Nextcloud config file? Vermutlich musstest du einige Pfade anpassen, nicht dass dabei auch der passwordsalt oder die instanceid geändert wurde.

  • kannst du mal ein Passworthash aus der alten Datenbank mit der neuen Datenbank vergleichen? Also einmal direkt nach dem importieren, einmal nach dem Passwort zurücksetzen und wieder auf das gleiche setzen.

    Oh man, ich war zu langsam mit dem Editieren, sry für den Doppelpost:


    Worauf ich mit den Hashes hinauswollte:

    Nextcloud benutzt ab PHP7.2 den argon2-hash. Das muss aber in PHP reinkompiliert sein. Ist es das nicht, fällt NC auf bcrypt zurück. Zu erkennen ist as an der 1 oder 2 am Anfang der Hashes. Es kann durchaus sein, dass deine alte PHP-Version das konnte und die Netcup PHP-Version nicht.

    Vielleicht kannst du im Webhostingpanel verschiedene PHP-Versionen ausprobieren. Es gibt da welche von Netcup kompiliert und welche aus den Paketquellen. Die Sury-Pakete sollten argon2 kompatibel sein

  • Vielleicht kannst du im Webhostingpanel verschiedene PHP-Versionen ausprobieren.

    Ich werd verrückt! Das ist es!


    Ich habe von der PHV Version laut 7.2.19 auf "7.2" gewechselt und siehe da, alle Logins funktionieren!


    Vielen Dank an euch!


    Nun ist dort aber das Problem, dass in dieser Version der OpCache fehlt... Man kann es drehen und wenden wie man will. Irgendwas fehlt immer.

    Webhosting 8000, mehrere Wollmilchsäue

  • Und bei der anderen Version hat der OPCache nicht "gefehlt". Ich schreibe das in Anführungszeichen, weil Nextcloud das immer behauptet, wenn die Einstellungen des OPCache nicht mindestens so hoch wie die von Nextcloud geforderten Werte sind. Ich habe das in einem anderen Webspace probiert, wo ich die Werte setzen kann. Etwas drunter und der OPCache war angeblich nicht aktiviert, wieder auf den geforderten Wert zurück und der OPCache wurde nicht mehr angemeckert. Auf die Idee, dass es damit zusammenhängen könnte, bin ich durch eine Google-Suche gestossen.


    Insbesondere

    Code
    opcache.max_accelerated_files=10000
    opcache.memory_consumption = 128

    scheint hier geprüft zu werden.

  • Da du dich grad mit Nextcloud hier bei NC beschäftigst, stelle ich einmal eine Zwischenfrage:


    Hast du deinen Data-Ordner innerhalb der Nextcloud Installation liegen?


    Ich habe versucht diesen außerhalb von httpdocs in files unterzubringen, bekomme aber immer Probleme mit den Schreibrechten.

  • Ist httpdocs dein Nextcloud-Installationsverzeichnis? Dann könnte es ein open_basedir Problem sein und du müsstest in den PHP-Einstellungen die Einstellung für open_basedir verwenden, die den Zugriff auf den gesamten Webspace zulässt und nicht nur in und unterhalb deines Dokumenten-Stammverzeichnisses.

  • Ist httpdocs dein Nextcloud-Installationsverzeichnis? Dann könnte es ein open_basedir Problem sein und du müsstest in den PHP-Einstellungen die Einstellung für open_basedir verwenden, die den Zugriff auf den gesamten Webspace zulässt und nicht nur in und unterhalb deines Dokumenten-Stammverzeichnisses.

    Genau das ist das Problem. In den Webhostingtarifen kann man dies nur durch open_basedir regulieren und da gibt es halt nur die 2 Optionen: Dokumentenstamn oder gesamter Webspace zugänglich machen.

  • Nun ist die Frage, was sicherer/unsicherer ist:

    Den Data-Ordner im NextCloud-Verzeichnis lassen

    "unsicherer"

    OpenBaseDir freigeben.

    "sicherer"


    Die Gefahr, dass sich in der Anwendung eine Sicherheitslücke befindet, die Zugriff auf Dateien gibt, existiert bei beiden Lösungen.

    Per OpenBaseDir erzwingt man jedoch, dass per Anwendung auf die Dateien zugegriffen werden muss. Wenn die Dateien im Stammverzeichnis (httpdocs) oder einem Unterordner davon liegen, sind sie (theoretisch) von außen aufrufbar. Dieses Risiko wird minimiert, wenn die zu schützenden Dateien parallel zum Stammverzeichnes liegen.

  • Ah - daran liegt es...


    Nun ist die Frage, was sicherer/unsicherer ist:

    Den Data-Ordner im NextCloud-Verzeichnis lassen oder OpenBaseDir freigeben.

    Kommt drauf an ... Im ersten Fall muss die Sicherheit eben dadurch hergestellt werden, dass das Data-Verzeichnis (im Falle der Verwendung des Apache) per .htaccess vor direktem Zugriff geschützt wird. Im zweiten Fall besteht die Sicherheit darin, dass der Webserver nicht auf das außerhalb liegende Verzeichnis zugreifen kann. Dafür muss dann eben open_basedir das Data-Verzeichnis beinhalten.


    Im netcup-Webhosting sehe ich es prinzipiell als sicherer an, das Data-Verzeichnis in Nextcloud-Verzeichnis zu belassen. Dann ist das Data-Verzeichnis durch die .htaccess geschützt und es muss nicht gleich der gesamte Webspace für den Zugriff durch PHP freigegeben werden. Das klappt natürlich nur bei Verwendung des Apache, andere Webserver werden (hoffentlich) andere Schutzmechanismen zur Verfügung stellen. Wenn nicht - oder wenn man diese im Webhosting nicht nutzen kann - muss das Data-Verzeichnis eben tatsächlich raus aus dem Nextcloud-Verzeichnis um sicher zu sein.


    Edit: Nextcloud bringt eine entsprechende .htaccess im Data-Verzeichnis sowieso mit.

  • Dann ist das Data-Verzeichnis durch die .htaccess geschützt und es muss nicht gleich der gesamte Webspace für den Zugriff durch PHP freigegeben werden.

    Da ich es für netcup tatsächlich nicht weiß: Kann man hier nicht nur das /data-Verzeichnis zusätzlich mit in OpenBaseDir aufnehmen? Dann ist ja konkret nur das zusätzlich freigegeben und nicht "der gesamte Webspace".

  • Da ich es für netcup tatsächlich nicht weiß: Kann man hier nicht nur das /data-Verzeichnis zusätzlich mit in OpenBaseDir aufnehmen? Dann ist ja konkret nur das zusätzlich freigegeben und nicht "der gesamte Webspace".

    Nein, im Webhosting hat man für open_basedir nur zwei vorkonfigurierte Optionen, welche jeweils die temporären Verzeichnisse und entweder den gesamten Webspace oder den Dokumentenstamm freigeben. Liegt also das Data-Verzeichnis im Webspace außerhalb des Dokumentenstamms, dann muss zwingend die Option mit dem gesamten Webspace freigegeben werden. Eine Erweiterung der Konfigurationsmöglichkeiten im WCP wäre da eventuell sinnvoll, z.B. die Angabe eines weiteren Verzeichnisses innerhalb des Webspace, das dann in open_basedir mit aufgenommen wird. Das hielte sich von der Komplexität in Grenzen und würde in vielen Fällen reichen. Die ganzen Symfony-Anwendungen brauchen das ja auch immer, ich muss da regelmäßig den gesamten Webspace freigeben.