EiWoMiSau-Nextcloud hat keinen Zugriff auf das data-Verzeichnis

  • Aus anderen Nextcloud-Themen konnte ich leider keine konkrete Lösung ableiten, von daher:

    Ich hatte bisher beim alten Provider eine Nextcloud auf Webhosting über eine externe Domain gut am Laufen (nichts Anspruchvolles, nur Familien-Orga - da geht das).


    Hier (EiWoMiSau) stoße ich mit gleicher Konfiguration bei Neuinstallation von NxCl 20 via Web-Skript auf Probleme. Weiß jemand etwas dazu? Das Problem müsste ja eigentlich bekannt sein, da ich ich sicher nicht der erste bei NC bin, der eine Nextcloud per Webinstaller-Skript auf ein Webhosting-Paket bringen möchte.


    Laut Admin-Übersicht fehlen Spalten in der DB; der dazu empfohlene SSH-occ-Korrektur-Aufruf läuft auch mit php73 nicht durch (Fatal Exception), und offenbar ist das (vorhandene!) Data-Verzeichnis nicht auffindbar ("///data" statt ordentlicher Server-Pfad) und ein /tmp Verzeichnis nicht eingereichtet. Das Skript sorgt ja eigentlich für passende Berechtigungen. Das Data Verzeichnis ist da, mein Hosting-User hat eigentlich alle erforderlichen Berechtigungen (an www-data komme ich ja wohl im Hosting nicht ran), aber offenbar "findet" der Webserver (der Defauit NGINX Proxy auf Apache) einfach den Pfad zum Verzeichnis nicht. Ich muss ihn aber auch nirgends eingeben. Irgendwas ist hier sehr faul, und ich wüsste gern was.


    Achja: Die jetzt schon beim zweiten Netcup-Hosting-Paket offenbar standardmäßige Fehlkonfiguration (?) (Pfad zu PHP im Include_Path: ".:/usr/local/php74/share/php74") habe ich auch schon korrigiert (".:/usr/local/php74/bin") und getestet. Open_Dir ist auf {DOCROOT}. Das Problem bleibt.


    Hat jemand einen Tipp?

  • Also bei meinem Webhosting ist das mit Problem mit dem PHP-Aufruf von der Technik korrigiert worden. Ich fürchte da fehlt eibfach was in deren Installationsskript für neue Webhostingserver. Mir wurde gesagt, dass der Fix in der Cloud ausgerollt würde. Vielleicht sollten die auch mal an das Installationsskript für neue Server ran. Ich würde es dem Support mrlfrn und gleich darauf hinweisen, dass du das jetzt schon bei mehreren Webhostings hattest, es also wohl ein systematisches Problem ist und kein Einzelfall. Vielleicht hilft es ja. Kann eigentlich nur im Interesse des Supports bzw netcup sein, wenn sie das nicht nachträglich für jeden Kunden korrigieren müssen.


    Die Sache mit dem Data-Verzeichnis passiert einfach deswegen, weil der Pfad wegen chroot auf der Konsole anders ist als im Webprozess. Die Lösung von KB19 mit zusätzlicher Konfig-Datei habe ich ja im anderen Thread nochmal gepostet. Bei dir sucht die Nextcloud jetzt das Datenverzeichnis im in der config.php angegebenen Verzeichnis, wo es natürlich dank der Chroot-Umgebung nicht zu finden ist. Hat bei mir auch einige Zeit gedauert, einige Wochen lang habe ich tatsächlich die App für occ per Webzugriff benutzt, was grundsätzlich keine gute Idee ist für Kommandos, die eigentlich im Wartungsmodus laufen sollten. Das /tmp-Verzeichnis würde ich fast mal Nextcloud "anlasten", es sind ja alle Berechtigungen vorhanden um das anzulegen bei der Installation. Oder es gibt auch hier wieder Verwirrung mit den Pfaden. Nextcloud ist grundsätzlich eher auf Server zugeschnitten und schlägt sich mit solchen Kuriositäten wie Chroot nicht lange rum.

  • Vielleicht sollten die auch mal an das Installationsskript für neue Server ran. Ich würde es dem Support mrlfrn und gleich darauf hinweisen, dass du das jetzt schon bei mehreren Webhostings hattest, es also wohl ein systematisches Problem ist und kein Einzelfall. Vielleicht hilft es ja. Kann eigentlich nur im Interesse des Supports bzw netcup sein, wenn sie das nicht nachträglich für jeden Kunden korrigieren müssen.

    Den Eindruck habe ich auch - Mache ich gleich mal.

    Zitat

    Die Sache mit dem Data-Verzeichnis passiert einfach deswegen, weil der Pfad wegen chroot auf der Konsole anders ist als im Webprozess. Die Lösung von KB19 mit zusätzlicher Konfig-Datei habe ich ja im anderen Thread nochmal gepostet. Bei dir sucht die Nextcloud jetzt das Datenverzeichnis im in der config.php angegebenen Verzeichnis, wo es natürlich dank der Chroot-Umgebung nicht zu finden ist. (...) Nextcloud ist grundsätzlich eher auf Server zugeschnitten und schlägt sich mit solchen Kuriositäten wie Chroot nicht lange rum.

    Danke, das klingt nach der Zusammenfassung für ein Standard-Problem, die ich gesucht habe. Gesehen hatte ich es, mich aber ohne Aussage "Ja, muss so, ist richtig" ;) vor dem Rumbasteln an Code gedrückt (Hinterher sind das die Stellen, an denen man oder Dritte sich wundert, warum das System irgendwie anders als erwartet verhält...).


    Allerdings lief Nextcloud bei meinem Alt-Anbieter in chrooted Webspace völlig mucken-frei - Irgendwas ist hier also anders konfiguriert (für das Nextcloud dann sicher ein geeignetes Indikator-Programm ist :) ).

  • Achja: Die jetzt schon beim zweiten Netcup-Hosting-Paket offenbar standardmäßige Fehlkonfiguration (?) (Pfad zu PHP im Include_Path: ".:/usr/local/php74/share/php74") habe ich auch schon korrigiert (".:/usr/local/php74/bin") und getestet. Open_Dir ist auf {DOCROOT}. Das Problem bleibt.

    Hm... In der Lösung von killerbees19 ist auch dieser Pfad im Screenshot zu sehen... Wenn es bei ihm funktioniert, ist der wohl doch nicht das Problem.

  • Ja, open_basedir kann so bleiben., das data-Verzeichnis liegt ja sowieso unterhalb der document root/Dokumentenstamm und es muss tatsächlich durch die von Nextcloud angelegte .htaccess geschützt werden.


    Das hier solltest du halt in jedem Fall machen, der Rest ist nice to have. Aber mit dieser Datei kann dein occ von der Kommandozeile auf das Data-Verzeichnis zugreifen und auch der Apache/PHP im Webprozess.

    https://github.com/froonix/web…ud/config/data.config.php

  • Danke - Das hilft mir schon einmal deutlich! Ich würde es aber nicht in /Nextcloud/Nextcloud/config, sondern direkt in .../<subdomain>/config laden (wenn NC unter . installiert wird) - richtig?

    EDIT: Versuch macht kluch - Es hat geklappt, OCC muckt nicht mehr, dann kann ich endlich migrieren. Danke für die Geduld!

  • Bei mir klappt occ im chron-Fenster prima, aber nun brauche ich

    Code
    sudo -u www-data php /var/www/nextcloud/updater/updater.phar

    da das nextcloud backup in das ngxi läuft. Besteht da eine Chance, das im chronfenster oder in der ssh shell mit geeigneten Rechten auszuführen?

  • Einfach ohne sudo -u www-data aufrufen?


    (Pfade dahinter müssen natürlich trotzdem angepasst werden.)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Einfach ohne sudo -u www-data aufrufen?


    (Pfade dahinter müssen natürlich trotzdem angepasst werden.)

    Ich denke, der user passt nicht und darf daher nicht das log schreiben. Das ist die Fehlermeldung:


    Could not open updater.log


    PHP Warning: fopen(/var/www/vhosts/hosting112345.a2e5e.netcup.net/mycloud/data/updater.log): failed to open stream: No such file or directory in phar:///mycloud/updater/updater.phar/lib/Updater.php on line 1110

  • Nun nun läuft das backup ins timeout und ich habe hier gelesen, das php-timeout läßt sich bei hostingpaketen nicht erhöhen.

    Ok, das ist natürlich ungünstig. Laut #145 kann man das Backup beim Web-Upgrade (aus gutem Grund) ohne manuelle Codeänderung auch nicht deaktivieren.


    Eventuell wäre es sinnvoll, wenn Du ein Issue bei den Entwicklern eröffnest: https://github.com/nextcloud/updater/issues


    Die Tatsache, dass er das Logfile trotz geändertem Datenverzeichnis an der falschen Stelle sucht klingt wie ein Bug.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Hallo zusammen,


    Eventuell kann ich da ein wenig Licht ins Dunkel bringen. Das beschriebene Problem (OCC geht, updater.phar macht Probleme) hatte ich nämlich ebenfalls und mich daher auf Ursachensuche begeben.


    Ich habe ebenfalls das Data-Directory ähnlich wie unter https://github.com/froonix/web…ud/config/data.config.php in einer Zusatz-Config namens netcup.config.php dynamisch angepasst.


    Ich habe dafür eine Zusatz-Config genommen und die Anpassung nicht direkt in die config.php geschrieben, da sonst wenn man in der Nextcloud-Instanz Änderungen im Admin-Bereich vornimmt oder die Cloud updatet, der Pfad dann sobald die Config seitens Nextcloud mal angepasst wird, sofort wieder mit einem fixen Pfad überschrieben werden würde.

    Nextcloud unterstützt nämlich zusätzliche Config-Dateien im Config ordner - Werte in diesen Zusatzdateien überschreiben die Werte aus der config.php - sodass man Werte nach belieben anpassen kann, ohne sich Sorgen machen zu müssen, dass die irgendwann überschrieben werden. Siehe: https://docs.nextcloud.com/ser…#multiple-config-php-file


    Ich denke nach dem selben Prinzip wird das auch cup gemacht haben.


    Ich habe mir jetzt mal den Code der updater.phar Datei angesehen. Wie sich herausgestellt hat, liest diese nur die config.php und keine weiteren Konfigurationsdateien aus. Somit funktioniert der Fix via zusätzlichen Config-Datei problemlos im Alltagsbetrieb, jedoch nicht für den Updater. Zur Gegenprobe habe ich mal temporär den Pfad-Fix direkt in die config.php geschrieben, und sofort hatte auch die updater.phar Datei keine Probleme mehr. Das ist aber wie bereits beschrieben wegen der Überschreibungsproblematik keine wirkliche Lösung.


    Ich werde später mal einen Issue im Nextcloud-Repo aufmachen und diesen hier via Edit verlinken, mal schauen was dabei heraus kommt.


    Edit: Hier der Issue: https://github.com/nextcloud/updater/issues/384