Data Verzeichnis im/nicht im Webroot / Kein Update auf 19.4, da data nicht data heißt

Mal kurz angemerkt.

Bin vor einigen Jahren von owncloud gekommen.
Unter OC war die Empfehlung, das DATA-Verzeichnis außerhalb vom Web-Root anzulegen. Fragt mich nicht, ich habe auch keine Zeit, die Quellen zu suchen. Das war ein vermeintliches Security-Feature - und so habe ich es auf allen Instanzen gemacht.
Der Umstieg lief problemlos. Nextcloud hat diese Konstellation unterstützt und niemals zu einem Problem gemacht.

Im Gegensatzt zu Owncloud funktionierten danach auch alle Updates unter Nextcloud reibungslos und perfekt. Das war grandios!!!
Endlich liefen alle Updates sauber durch!!! Wir reden hier übrigens von shared webhosting - kein root server oder sowas, wo man ja ganz anders dran gehen kann!!!

Seit Nextcloud 19 gibt es aber nur noch Theater. [Boahh, einfach nur z.K.]

Bei/Während/Nach dem Update von 19.2 auf 19.3 ist es mit Biegen und Brechen sowie mit einem riesengroßen Haufen tricky Tricks gelungen, das DATA-Verzeichnis - hinein - in das NC-Verzeichnis zu verschieben - da es anders nun gar nicht mehr funktioniert.

Für wenige Monate lief es wieder rund.

Nun kommt Nextcloud 19.4.

Natürlich heißen meinen Data-Verzeichnisse auf den Servern NICHT “data” - UND SCHON WIEDER GEHT ES NICHT WEITER.
Das Update bricht ab. Der Updater macht einen

Check for expected files

und moniert, den abweichenden Namen für das Data-Verzeichnis.

Ich frage mich: HABT IHR NOCH ALLE LATTEN AM ZAUN? Geht jetzt das rumbiegen, Datenbank aufbohren usw. in die nächste Runde???
Das ist beinahe ein Grund, jetzt auch Nextcloud in die Tonne zu kloppen. Keine Lust mehr auf solche Faxen.

ES IST NIRGENDWO BESCHRIEBEN ODER EIN THEMA. NIEMALS EIN HINWEIS IN DEN RELEASE NOTES. MEGA ÜBEL.

so schade.

@root1 willkommen im Forum und dass Du hier DIch auch am Projekt beteiligt hast.

Weil Du keine Fragen stellst, habe ich mal eine Frage an DICH.

Stellen wir uns mal vor: Du betreibst eine Kneipe… und die ist attraktiv, es kommen immer mehr Menschen und fühlen sich bei dir wohl. Sie kommen sogar von der Kneipe gegenüber, die zwar zuerst da war aber an Attraktivität verliert (as welchen Gründen auch immer - vielleicht ist die Farbe an den Wänden deiner Pinte einfach gefälliger und die Leute dürfen die Musik hören, die in einer Jukebox steckt und nicht immer nur die Plattensammlung vom Besitzer der Butze gegenüber).
Da kommt eines Tages jemand Neues in deinen Laden, stellt sich kurz als Exbesucher des Etablissements von gegenüber vor und kotzt dann eimerweise und ohne viel Federlesens auf den Thresen. (Weil er meint, jemand hätte defacto die Jukebox ad absurdum geführt, indem er nur 1 Single drin hätte, die dafür aber 100x. Oder was auch immer.)

Hier also die Frage: Wie würdest du als Kneipier oder auch nur als anwesendes Publikum reagieren?

Lange Rede - kurzer Sinn: Ich persönlich finde Deinen Auftritt hier unter aller Kanone, unhöflich und unverschämt. Und es gibt Hinweise darauf, dass Du das ebenfalls so siehst (warum solltest Du dir sonst extra einen neuen Account machen?)

Tipp (fürs Leben): Wenn Du Kritik hast, dann bring sie bitte sachlich und fundiert vor. Dann ist man sicher auch eher bereit, darauf einzugehen… Auf deine oben gezeigte Weise funktioniert das i.d.R. nicht. Beispielsweise ich kann Dich so nicht wirklich ernst nehmen.

Danke für Deine Zeit und Dein Verständnis.
Jimmy

5 Likes

Nextcloud empfiehlt wie ownCloud das Datenverzeichnis außerhalb des Webroot zu platzieren: https://docs.nextcloud.com/server/19/admin_manual/installation/harden_server.html#place-data-directory-outside-of-the-web-root

Ich betreibe eine Nextcloud Instanz, die als ownCloud 6 geboren wurde und dann sukzessive bis Nextcloud 19.0.4 aktualisiert wurde. Das Datenverzeichnis lag dabei schon immer außerhalb des Installationsverzeichnisses.

Ich glaube nicht, dass die ursprüngliche Ursache deiner Probleme am externen Datenverzeichnis lag.

Es gibt hier im Forum einen Thread in dem beschrieben wird, wie man das Datenverzeichnis verschieben kann. Vielleicht findest du darin eine Hilfestellung.

Na gut, mein Statement hätte ich neutraler formulieren können, war aber als Hilferuf gedacht. Und zwar gerade aus dem Grund, da ich seit ewigen Zeiten beide Lösungen verwende, die Grundidee fantastisch finde - und seit den ersten Tagen propagiere. Bedeutet, seit weit über einer Dekade ist mit mir bei meinen beruflichen oder privaten Stationen eine Cloud eingezogen, oder war vorhanden und oder habe ich migriert. Dabei habe ich eine Menge Erfahrungen gemacht, im Einsatz bei einem Webhoster oder auf eigenen Servern - und mich mit zahlreichen Problemen auseinandergesetzt. Diese Erkenntnisse und Lösungswege habe ich immer wieder auch im eigenen --> Blog veröffentlicht und weitergegeben.

@JimmyKater
Accounts und Mitgliedschaften in Webforen hat man ja genug. Bislang schien es mir, als brauchte ich hier nicht noch einen weiteren. Ich wollte auch keinen neuen. Aber wegen dieser Frage musste ich nun. Vielen Dank, dass Du trotz der Irritationen geantwortest hast. Der Meinungsaustausch an einer Theke würde mir auch Spaß bereiten. Ich brauche dazu aber keine Jukebox.

Seit einigen Monaten schiebe ich die DATA-DIRs hin und her und bohre in der Datenbank, damit es wieder läuft.
Nextcloud zeigt sich sich extrem empfindlich. Einmal kurz angefasst und schon lautet der Fehler: .ocdata sei nicht vorhanden. Ist eigentlich vollkommenener Käse, liegt ja da. Wird aber ignoriert oder übersehen oder sonstewas. Sehr ärgerlich ist nur, dass unmittelbar nach und mit dieser Meldung auch genau nichts mehr funktioniert. Damit schmiert die ganze Installation ab und erfordert Korrekturen in der Datenbank.

Jetzt mache ich nochmal einen kurzen Sprung zurück, denn das war einer der Gründe, weshalb ich von Owncloud zu Nextcloud wechselte. Mit Nextcloud gab es überhaupt keine Probleme beim Update. So geschmeidig wie die Oberfläche, liefen die Updates geschmeidig durch - auch auf einem shared Web-Space bei einem Webhoster. Nicht ein einziges Mal gab es Schwierigkeiten, seit Nextcloud 9 im Jahre 2017.

Mitte September 2020 beim Update von 19.0.2 auf 19.0.3 zeigten sich erstmals ERNSTHAFTE Probleme. Es war kein Update möglich, da DATA außerhalb des WebRoot-Verzeichnisses lag. Und mit dem missglückten Update war ZUDEM auch noch die gesamte Installation abgeschmiert! Kein Login möglich. Nextcloud tat so, als sei gar nichts vorhanden. Mit Verlaub, da geht einem der Puls schon etwas höher, oder etwa nicht? Also habe ich data hineingezogen und die Pfade in der Datenbank angepasst und das Ding gerettet. Daraufhin lief das Update durch und Nextcloud 19.0.3 für einen Monat sauber weiter. Alle Daten für alle User vorhanden, Synchronisation von Adressen, Kalendern mit diversen Clients - alles geschmeidig.

Einen Monat später deutet sich das Update auf 19.0.4 an. Bei reibungslosem Betrieb gehe ich davon aus, dass das Update nun wieder wie gewohnt geschmeidig durchläuft. TUT ES ABER NICHT.

@Bernie_O
Vielen Dank, diesen Hinweis habe ich gesucht. Also lag ich doch nicht falsch. Ist es doch weiterhin die Empfehlung, das data-Verzeichnis außerhalb vom Webroot zu platzieren. Dementsprechend liegen/lagen in allen Installationen die data-Verzeichnisse außerhalb - in einigen nun innerhalb [grrr]. Allerdings auch mit einem abweichenden Namen.

Aber noch weniger verstehe ich, dass es dann, zumal das Update auf 19.0.3 erfolgreich war und einen Monat lief, nun wieder mit dem Update auf 19.0.4 erneut zu einem Problem wird.

Wie oben bereits ausgeführt macht der Updater einen

Check for expected files

sucht offenbar data // data heißt aber anders // checkt der Updater aber nicht

und bricht ab.

So hänge ich aktuell auf 19.0.3 und komme nicht weiter.

@Bernie_O: Das hat doch eine ähnliche Historie. Wie heißt denn Dein data-Verzeichnis?

Mein Datenverzeichneis heißt (aus historischen Gründen): owncloud_data - es liegt eine Ebene höher als das webroot.

Derartige Probleme mit dem data-Verzeichnis hatte ich noch nie.

Absoluten Pfad zum data-Verzeichnis in die config.php eintragen ('datadirectory' => '/pfad/zu/owncloud_data',).
Wenn Nextcloud der abweichende Name und Ort des data-Verzeichnisses nicht bekannt ist, nimmt es halt den default-Namen im default-Verzeichnis.

Zusätzlich vll. noch Owner und Permissions des data-Verzeichnisses checken.

Vielen Dank für die weiteren Hinweise.
File und directory permissions waren/sind okay.

In meiner config.php steht

'datadirectory' => '/var/www/vhosts/hosting.mydomain.net/www-nextcloud/01-cloudata',

Wie gesagt, bis zur 19.0.2 lag das Data-Verzeichnis eine Ebene höher:
/var/www/vhosts/hosting.mydomain.net/01-cloudata

Doch als die Probleme auftraten habe ich das Data-Verzeichnis in DocRoot reingeschoben, die Datenbank korrigiert und danach lief das Update durch auf 19.0.3 - und diese Version ca. 4 Wochen vollkommen unproblematisch.

Das sind die letzten Einträge im updater.log:

2020-10-19T00:56:41+0200 j3zo8ck8OT [info] request to updater
2020-10-19T00:56:41+0200 j3zo8ck8OT [info] currentStep()
2020-10-19T00:56:41+0200 j3zo8ck8OT [info] show HTML page
2020-10-19T00:56:41+0200 j3zo8ck8OT [info] current version: 19.0.3 build time: 2020-09-09T11:44:22+00:00 02a6cac39ddd619b2a0710e3fba703f3d72ee13d
2020-10-19T00:56:41+0200 j3zo8ck8OT [info] getUpdateServerResponse()
2020-10-19T00:56:41+0200 j3zo8ck8OT [info] updaterServer: https://updates.nextcloud.com/updater_server/
2020-10-19T00:56:41+0200 j3zo8ck8OT [info] releaseChannel: stable
2020-10-19T00:56:41+0200 j3zo8ck8OT [info] internal version: 19.0.3.1
2020-10-19T00:56:41+0200 j3zo8ck8OT [info] updateURL: https://updates.nextcloud.com/updater_server/?version=19x0x3x1xxxstablexx2020-09-09T11%3A44%3A22%2B00%3A00+02a6cac39ddd619b2a0710e3fba703f3d72ee13dx7x4x11
2020-10-19T00:56:42+0200 j3zo8ck8OT [info] getUpdateServerResponse response: Array
(
    [version] => 19.0.4.2
    [versionstring] => Nextcloud 19.0.4
    [url] => https://download.nextcloud.com/server/releases/nextcloud-19.0.4.zip
    [web] => https://docs.nextcloud.com/server/19/admin_manual/maintenance/upgrade.html
    [changes] => https://updates.nextcloud.com/changelog_server/?version=19.0.4
    [autoupdater] => 1
    [eol] => 0
    [signature] => rg2l/a/fYyVG36nM1Vraz+0tafxvHovk+KzkZ+9k2v3/EGg7zumk3e1vX84gA9Au
RlE/aDbwKPrhdVe/+xRTd/1sy7YFbCH65l+8xpR6eSFoD4UkvthhlqvAiJHd7aRO
zqIvA2UAN28aKaAqc4Pq9DAwwchRl8PqX6+LvK2DiuMaMmYKSJOOBIpAMg6JEEeq
Ljf4wARZVM9Euc0jRwgGvg==
)

2020-10-19T00:56:42+0200 j3zo8ck8OT [info] checkForUpdate() Array
(
    [version] => 19.0.4.2
    [versionstring] => Nextcloud 19.0.4
    [url] => https://download.nextcloud.com/server/releases/nextcloud-19.0.4.zip
    [web] => https://docs.nextcloud.com/server/19/admin_manual/maintenance/upgrade.html
    [changes] => https://updates.nextcloud.com/changelog_server/?version=19.0.4
    [autoupdater] => 1
    [eol] => 0
    [signature] => rg2l/a/fYyVG36nM1Vraz+0tafxvHovk+KzkZ+9k2v3/EGg7zumk3e1vX84gA9Au
RlE/aDbwKPrhdVe/+xRTd/1sy7YFbCH65l+8xpR6eSFoD4UkvthhlqvAiJHd7aRO
zqIvA2UAN28aKaAqc4Pq9DAwwchRl8PqX6+LvK2DiuMaMmYKSJOOBIpAMg6JEEeq
Ljf4wARZVM9Euc0jRwgGvg==
)

2020-10-19T00:56:42+0200 j3zo8ck8OT [info] getChangelogURL()
2020-10-19T00:56:42+0200 j3zo8ck8OT [info] end of checkForUpdate() Update to Nextcloud 19.0.4 available. (channel: "stable")<br /><span class="light">Following file will be downloaded automatically:</span> <code class="light">https://download.nextcloud.com/server/releases/nextcloud-19.0.4.zip</code><br /><a class="external_link" href="https://nextcloud.com/changelog/#19-0-4" target="_blank" rel="noreferrer noopener">Open changelog ↗</a>
2020-10-19T00:56:45+0200 4drS7GqMfo [info] request to updater
2020-10-19T00:56:45+0200 4drS7GqMfo [info] currentStep()
2020-10-19T00:56:45+0200 4drS7GqMfo [info] POST request for step "1"
2020-10-19T00:56:46+0200 4drS7GqMfo [info] startStep("1")
2020-10-19T00:56:46+0200 4drS7GqMfo [info] checkForExpectedFilesAndFolders()
2020-10-19T00:56:46+0200 4drS7GqMfo [error] POST request failed with UpdateException
2020-10-19T00:56:46+0200 4drS7GqMfo [error] Exception: UpdateException
Message: 
Code:0
Trace:
#0 /var/www/vhosts/hosting.mydomain.net/www-nextcloud/updater/index.php(1339): Updater->checkForExpectedFilesAndFolders()
#1 {main}
File:/var/www/vhosts/hosting.mydomain.net/www-nextcloud/updater/index.php
Line:395
Data:
Array
(
    [0] => 01-cloudata
)


2020-10-19T00:56:46+0200 4drS7GqMfo [info] rollbackChanges("1")
2020-10-19T00:56:46+0200 4drS7GqMfo [info] unlink .step
2020-10-19T00:56:46+0200 4drS7GqMfo [info] end of  rollbackChanges()

Ich hätte noch eine ungünstige PHP-Version in Verdacht gehabt.

Auf der gleichen Server-Instanz läuft in einem parallelen Verzeichnis eine --> Current version is 19.0.2 seit Ende August, nackt, blanko, frisch.
Jetzt versuche ich gerade diese Version hochzuziehen und

Initializing
Current version is 19.0.2.
Update to Nextcloud 19.0.4 available. (channel: "stable")
Check for expected files
Check for write permissions
Create backup
...

da bleibt der Web-Updater hängen mit einem --> Timeout !?!

Ich gucke mir das ein paar Minuten an, lade die Startseite neu und erhalte einen PHP-Error

Warning: is_writable(): open_basedir restriction in effect. ...

Im Backend unter --> Plesk schalte ich versuchsweise hin und her zwischen den zwei möglichen Einstellungen

{WEBSPACEROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions
{DOCROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions{:}{WEBSPACEROOT}{/}tmp

Die Session ist noch aktiv und ich lande auf der üblichen Startseite. Da freue ich mich und klicke - und schwups - es erscheint eine weiße Seite mit dem Hinweis

Ihr Datenverzeichnis ist ungültig. Stellen Sie sicher, dass eine Datei ".ocdata" im Wurzelverzeichnis des data-Verzeichnisses existiert.

Damit ist nun diese Nextcloud ebenfalls abgeschmiert.

Wegen der Plesk-Faxen denke ich, liegt das ganze Theater gar nicht an Nextcloud, sondern vermutlich am Webhoster??!!??? Der hat vor ein paar Tagen ein Update gefahren. Das ist zwar nicht mehr hosteurope, sondern netcup.

Damit wäre der Titel von diesem Thread leider auch vollkommen unzutreffend.

Jetzt fehlt nur noch, dass mir bei netcup auch noch die Blogs abrauschen.

Ich werde jetzt erst einmal Rücksprache halten, derweil nichts mehr anfassen, versuchen das Problem ausfindig zu machen und sofern möglich, hier weitere Erkenntnisse berichten.

Es lässt einem ja keine Ruhe.
Jetzt habe ich doch noch einen Test gemacht mit der zuvor vermeintlich abgeschmierten, parallelen Installation auf der gleichen Server-Instanz.
Diese war doch wieder erreichbar, nachdem ich im Backend unter --> Plesk die --> Einstellung für

open_basedir

geändert habe von bislang

{DOCROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions{:}{WEBSPACEROOT}{/}tmp

auf
{WEBSPACEROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions

Testweise habe ich nochmals zurückgestellt auf
{DOCROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions{:}{WEBSPACEROOT}{/}tmp

(übrigens, alle web apps liefen bis dato nur mit dieser einstellung)

ÜBERRASCHUNG: Jetzt kommt keine weiße Seite, sondern Nextcloud selbst (auf der index.php Startseite) greift die Fehlermeldung auf und zeigt an:
Ihr Datenverzeichnis ist ungültig. Stellen Sie sicher, dass eine Datei “.ocdata” im Wurzelverzeichnis des data-Verzeichnisses existiert.

Im Backend (Plesk) stelle ich nun --> die Einstellung für

open_basedir

auf
{WEBSPACEROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions

erhalte eine saubere Startseite, wie gewohnt ohne Fehlermeldung - jetzt der Knaller, kann problemlos updaten auf 19.0.4.

Also jetzt muss ich erst einmal überlegen, wie ich die Zähne wieder aus der Tischkante heraus bekomme und wie ich das nun für meine eigentliche NC Hauptinstallation umsetze.

@root1

Wir fassen mal deine Usererfahrung hier im Forum zusammen:

  • Du hast Dich schön ausgekotzt und Dich … naja… “entschuldigt” wäre zuviel gesagt. Du hast Dich vordergründig ansatzweise einsichtig gezeigt.
  • Du gibst kaum Infos raus über das problematische System
  • Dennoch gibt es Versuche, Dir zu helfen (hier gibt es sehr viele ausgesprochen nette User)
  • Am Schluss stellt sich raus, dass es überhaupt kein NC-Problem war sondern ein so genanntes externes Problem… (ich schwanke noch zwischen PLESK~ und Verständnis~)

Nun immerhin warst Du so fair und hast auch noch die Lösung gepostet. Danke dafür.

Du siehst hoffentlich selbst tatsächlich ein, dass Dein Auftritt hier in Teilen stark verbesserungswürdig war…
Ich hoffe also auf Deine entsprechende Einsicht bei zukünftigen Postings.

Happy nc’ing

1 Like

Verehrte Gemeinde,

ich hänge doch wieder fest mit einer 19.0.3., für die ein Update auf 19.0.4. ansteht.

Ich habe jetzt einen Screenshot gemacht.
Es ist wieder eine vollständig problemlos funktionierende Installation, bei der das Datenverzeichnis
a) umbenannt wurde, also nicht data heißt
b) das Datenverzeichnis innerhalb vom DOCROOT des Webservers liegt.

Nun sagt der Updater:

The following extra files have been found:

* 01_cloud_data
* tmp

01_cloud_data ist das Datenverzeichnis.

tmp ist leer, habe ich entfernt - nächster Versuch.

Nextcloud erkennt das eigene Datenverzeichnis nicht. Er begreift nicht, dass es anders heißt.

Wat steht denn in der CONFIG???

Da steht

'datadirectory' => 'ein-pfad-zu/htdocs/www-nextcloud/01_cloud_data',

Wie komme ich da nur weiter?

@root1
ich habe mehrere Nextcloud-Instanzen bei netcup und hatte noch nie Probleme.
Bei mir heißt das Verzeichnis allerdings nicht “htdocs” sondern “httpdocs”, aber das kann ja ein Schreibfehler sein.

Die Sache hat mich schon sehr interessiert, da ich bis jetzt meine Updates manuell über die Konsole (PuTTY) durchgeführt habe.

Aufwändiger Weise habe ich eine meiner Installationen mit einem Restore noch einmal auf die Version 19.0.3 zurückgesetzt und anschließend das data-Verzeichnis an einen anderen Ort verschoben. In der config.php habe ich diesen neuen Pfad nun geändert und konnte ohne Probleme in der Nextcloud weiter arbeiten.

Nun kam der von Dir erwähnte Aufruf des “hauseigenen” Updaters.

Was mir unendlich viel Zeit gekostet hatte, das war die heutige absolut schlechte Erreichbarkeit des Download-Servers. Da dies sehr häufig der Fall ist, habe ich mich an das manuelle Update gewöhnt.

Um hier zu einem erfolgreichen Abschluss zu kommen, da kann einem schon der Geduldsfaden reißen.

Schlussendlich lief aber Alles sauber durch und die Nextcloud war wieder auf Version 19.0.4.

Meine “open_basedir” Einstellungen stehen dabei auf Standard “{DOCROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions{:}{WEBSPACEROOT}{/}tmp”.

Das Verschieben des “data”-Verzeichnisses und das Editieren der config.php habe ich für den Test eigens mit dem “File Manager” von Plesk erledigt, obwohl ich sonst nur mit WinSCP arbeite.

Es muss also irgendwie an falschen Berechtigungen liegen.

Gruß
Crashandy

Nachtrag:
Der von Dir beim Updater angezeigte Fehler hätte eigentlich auch schon bei den “Sicherheits- & Einrichtungswarnungen” kommen müssen.

PHP-Memory-Cache ist ein netcup-Problem.

Der Themenkomplex sowie die Problematik um .ocdata taucht ja weiterhin auf. Es wurde an den folgenden Stellen eine Hilfestellung angesprochen, die womöglich seit NC 18 eine Lösung sein kann, die ich auch hier kurz anheften will:

Hallo @root1,

Die Sammlung der Topics hat nichts mit dem Thema “.ocdata” zu tun.

Auf welches der letzten Postings beziehst Du Deine Antwort?

Gruß

Ich weiß, dass sich die Themen hier etwas vermischen. Aber bei mir taucht die Meldung “Ihr Datenverzeichnis ist ungültig…” in jeder zweiten Session auf, bei Updates usw.

Als ich beim letzten (ursprünglichen s. o.) Update-Versuch noch davon ausging, dass die Probleme damit zusammenhängen könnten, dass das data-Verzeichnis außerhalb vom DOCROOT liegt, hatte ich zwischendurch u. a. die Fehlermeldung,

auf die ich dort verweise. Und an deren Ende eben auch den Hinweis …“Stellen Sie sicher, dass eine Datei “.ocdata” im Wurzelverzeichnis…”

Womöglich hängen die Probleme beim Update, bei laufenden Sessions usw. damit zusammen, dass die Konfiguration der → Background Jobs → /index.php/settings/admin → nicht optimal ist. Daher habe ich die Infos hier reingeschwenkt.