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.