NextCloud 15 Installation unter EiWoMiSau

  • Hallo,


    ich habe versucht auf meinem Webhostingpaket eine Nextcloud Instanz aufzusetzen.

    Also ZIP hochgeladen, Setup gestartet. Nextcloud selbst empfiehlt ja, den Data - Ordner nicht im selben Pfad liegen zu haben.

    Das hat sich allerdings irgendwie mit der open_basedir - Direktive von Plesk gebissen und nicht so ganz funktioniert, wie ich das eigentlich von früheren Installationen bei anderen Hostern gewohnt war.

    Setup lief daraufhin aber wie gewünscht durch. Nun habe ich allerdings das Problem, dass ich wenn ich mich einloggen möchte, die folgenden Fehlermeldungen von der Firefox Konsole ausgeworfen bekomme:



    So wie ich das verstehe, versucht er irgendwelche JavaScripts nachzuladen, die Nextcloud aber eigentlich (jedenfalls nach meinem Verständnis / (Irr)Glauben) selbst ausliefert. Dementsprechend sind die Buttons zwar animiert, lassen sich aber nicht drücken... Leider weiß ich hier wirklich nicht mehr weiter. Falls es bei der Ferndiagnose hilft, ich lasse die Installation unter einer Subdomain laufen über nginx und habe den HSTS Header Strict-Transport-Security "max-age=15552000; includeSubDomains" aktiviert.


    Über eine schnelle Hilfe aus der Community wäre ich unglaublich dankbar.


    Viele Grüße!

  • Hay,


    das Problem könnte Cross-site-scripting sein. Lädt denn alles von der Webseite (insbesondere javascript) von derselben Webseite oder kommt da was domainübergreifend? Wo liegt denn "script-src", etwas mit dem Namen in irgendwelchen Ordnern?


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Schon einmal vielen Dank für den Tipp. Allerdings hat auch das nicht ganz so wie geplant funktioniert:


    Über zusätzlichen Input / Hilfe wäre ich dankbar :)

  • Was für einen Browser nutzt du? Ich habe spontan mal eine Nextcloud auf meinem Webhosting aufgesetzt und konnte keine Probleme feststellen (also keine grundlegenden Probleme mit der aktuellen Version auf dem Webhosting)... Ich habe zwar keine Wollmilchsau, aber ich bezweifle das dies einen Unterschied macht...

  • Hay,


    ich habe irgendwo gelesen, der Fehler könnte auch mit bestimmten Browsererweiterungen (z.B. irgendwelche Anonymisierungserweiterungen) im Firefox auftreten.


    a) Mal mit einem anderen Browser probieren

    b) Firefox mal alle Extensions abschalten


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Dann versuche ich es noch mal über Chrome, vielleicht ändert das ja etwas!

  • Immerhin ein schon etwas anderer Fehler....

  • default-src 'none';base-uri 'none';manifest-src 'self';script-src 'nonce-Y...=';style-src 'self' 'unsafe-inline';img-src 'self' data: blob:;font-src 'self' data:;connect-src 'self';media-src 'self'


    Das ist die Standard Content Security Policy, die mir vom Webserver geschickt wird. Ist die vielleicht nicht ganz korrekt?


    Also Zusatzinfo (mMn. sollte das keinen Unterschied machen, aber vielleicht liege ich ja falsch): Ich nehme für jeden Neuinstallationsversuch die selbe DB, ohne vorher zu wipen, aber das sollte ja bei einem JS Problem keinen Unterschied machen oder?

  • Also ich würd die Datenbank vorsichtshalber schon leer machen vor der Neuinstallation. Vorab, mit nginx habe ich noch keine Nextcloud installiert. Ich gehe mal davon aus, du hast ein Lets Encrypt oder sonstiges SSL-Zertifikat für die verwendete Subdomain installiert?

    Der Versuch mit nginx interessiert mich aber auch, wobei ich dachte, man kann da keine eigene Konfiguration benutzen im Webhosting. Aber falls Du das zum laufen bringst mit nginx wäre ich definitiv daran interessiert wie. Wenn du bei der Installation Probleme wegen open_basedir hattest, kannst du versuchen, das im Plesk bei den PHP-Einstellungen zu ändern. Basically gibt es da nur zwei Auswahlmöglichkeiten. Entweder die erste, da ist (für PHP) nur Zugriff auf die document root und unterhalb freigegeben, oder eben die zweite, da ist die webspace root freigegeben, also praktisch der gesamte Webspace. Jeweils dann noch die Verzeichnisse, die PHP sonst noch so braucht (temporäres Verzeichnis usw.) Mit der zweiten Einstellung dürfte das open_basedir Problem weg sein. Sicherheitstechnisch allerdings eventuell bedenklich. Könnte mir vorstellen, dass da eventuell einige Dateien bei der Installation nicht geschrieben oder gelesen werden konnten.


    Mit Apache war die Installation halbwegs problemlos (Webhosting 8000) und es funktioniert auch soweit. Hier kann man ja die Daten innerhalb des document root lassen. Allerdings wird OPCache angemeckert und kein memcaching gefunden. Auch auf Daten über die Systemauslastung kann nicht zugegriffen werden und HSTS habe ich auch noch nicht aktiviert, falls das tatsächlich geht.

  • Also ich würd die Datenbank vorsichtshalber schon leer machen vor der Neuinstallation. Vorab, mit nginx habe ich noch keine Nextcloud installiert. Ich gehe mal davon aus, du hast ein Lets Encrypt oder sonstiges SSL-Zertifikat für die verwendete Subdomain installiert?

    Der Versuch mit nginx interessiert mich aber auch, wobei ich dachte, man kann da keine eigene Konfiguration benutzen im Webhosting. Aber falls Du das zum laufen bringst mit nginx wäre ich definitiv daran interessiert wie. Wenn du bei der Installation Probleme wegen open_basedir hattest, kannst du versuchen, das im Plesk bei den PHP-Einstellungen zu ändern. Basically gibt es da nur zwei Auswahlmöglichkeiten. Entweder die erste, da ist (für PHP) nur Zugriff auf die document root und unterhalb freigegeben, oder eben die zweite, da ist die webspace root freigegeben, also praktisch der gesamte Webspace. Jeweils dann noch die Verzeichnisse, die PHP sonst noch so braucht (temporäres Verzeichnis usw.) Mit der zweiten Einstellung dürfte das open_basedir Problem weg sein. Sicherheitstechnisch allerdings eventuell bedenklich. Könnte mir vorstellen, dass da eventuell einige Dateien bei der Installation nicht geschrieben oder gelesen werden konnten.


    Mit Apache war die Installation halbwegs problemlos (Webhosting 8000) und es funktioniert auch soweit. Hier kann man ja die Daten innerhalb des document root lassen. Allerdings wird OPCache angemeckert und kein memcaching gefunden. Auch auf Daten über die Systemauslastung kann nicht zugegriffen werden und HSTS habe ich auch noch nicht aktiviert, falls das tatsächlich geht.

    DAS war das "Problem"! Finde ich zwar sau schade, dass es nur mit Apache funktioniert, aber wenn es läuft, läuft es und ich will gar nicht weiter klagen :) Vielen Dank!

    Unter Apache läuft das Ganze wirklich einwandfrei... Warum es mit nginx nicht klappt, bleibt mir wohl erst einmal ein Rätsel... HSTS konnte ich aktiviert lassen.

  • DAS war das "Problem"! Finde ich zwar sau schade, dass es nur mit Apache funktioniert, aber wenn es läuft, läuft es und ich will gar nicht weiter klagen :) Vielen Dank!

    Da nicht für. Ich dachte eigentlich, dass Du auf nginx hier vielleicht besonderen Wert legst, weil es von der Performance her oft besser ist. Mein Webhosting 8000 ist von der Performance her zwar durchaus gut, aber nicht mit einem geeigneten Server vergleichbar. Das gilt erst recht für die EiWoMiSau, die kein garantiertes RAM hat und auch ein niedrigeres memory_limit.

    Zumindest in meiner installierten Nextcloud mit Apache werden recht ausgiebig .htaccess Dateien verwendet. Unter anderem auch im data-Verzeichnis, wo in der .htaccess unter anderem das drinsteht:

    Code
    <IfModule mod_authz_core.c>
    # Apache 2.4
    Require all denied
    </IfModule>

    Damit wird der direkte Zugriff auf Dateien in diesem Verzeichnis und den darunterliegenden Verzeichnissen verhindert, soweit nicht wieder in der dortigen .htaccess erlaubt.


    nginx selbst dagegen interpretiert die .htaccess Dateien nicht. nginx würde also z.B. eine im data-Verzeichnis liegende Textdatei ausliefern. Deswegen soll das data-Verzeichnis aus dem document root raus, damit ist es automatisch geschützt. Muss dann doch auf irgendein Unterverzeichnis zugegriffen werden, kann das mittels eines SymLinks erreicht werden, der seinerseits im oder unterhalb des document roots liegt und auf das benötigte Unterverzeichnis verweist. Es gibt allerdings auch Konverter, die .htaccess Dateien in eine entsprechende nginx-Konfiguration umsetzen.

  • Da nicht für. Ich dachte eigentlich, dass Du auf nginx hier vielleicht besonderen Wert legst, weil es von der Performance her oft besser ist. Mein Webhosting 8000 ist von der Performance her zwar durchaus gut, aber nicht mit einem geeigneten Server vergleichbar. Das gilt erst recht für die EiWoMiSau, die kein garantiertes RAM hat und auch ein niedrigeres memory_limit.

    Zumindest in meiner installierten Nextcloud mit Apache werden recht ausgiebig .htaccess Dateien verwendet. Unter anderem auch im data-Verzeichnis, wo in der .htaccess unter anderem das drinsteht:

    Code
    <IfModule mod_authz_core.c>
    # Apache 2.4
    Require all denied
    </IfModule>

    Damit wird der direkte Zugriff auf Dateien in diesem Verzeichnis und den darunterliegenden Verzeichnissen verhindert, soweit nicht wieder in der dortigen .htaccess erlaubt.


    nginx selbst dagegen interpretiert die .htaccess Dateien nicht. nginx würde also z.B. eine im data-Verzeichnis liegende Textdatei ausliefern. Deswegen soll das data-Verzeichnis aus dem document root raus, damit ist es automatisch geschützt. Muss dann doch auf irgendein Unterverzeichnis zugegriffen werden, kann das mittels eines SymLinks erreicht werden, der seinerseits im oder unterhalb des document roots liegt und auf das benötigte Unterverzeichnis verweist. Es gibt allerdings auch Konverter, die .htaccess Dateien in eine entsprechende nginx-Konfiguration umsetzen.

    Hi,


    ich persönlich mag nginx einfach lieber, weil ich da bisher einfach bessere Erfahrungen, als mit Apache gemacht habe (finde die Configfiles lesbarer, aber das ist ja Geschmackssache). Bei den Gelegenheiten, wo ich nginx + Nextcloud bisher selbst deployen konnte, gab es mit den .htaccess Dateien aber auch keinerlei Probleme. Bin allerdings auch nicht informiert, warum und wie NC dann trotzdem noch weiterhin funktioniert (kam auf .htaccess geschützte Bereiche auch nicht mit nginx drauf).


    Vielen Dank noch einmal und viele Grüße!