Serverfehler unter Nextcloud 34.0.1

[sreum-sys]

Beim aufrufen der App entsteht ein Serverfehler.

[index] Fehler: Call to undefined method OC\Server::getConfig() GET /index.php/apps/occweb/ von 00.00.00.00 von XXXXX um 08.07.2026, 14:59:06

{"reqId":"ak5JmgK8vmbnvZ6grK77IQAAABI","level":3,"time":"2026-07-08T12:59:06+00:00","remoteAddr":"00.00.00.00","user":"user","app":"index","method":"GET","url":"/index.php/apps/occweb/","scriptName":"/index.php","message":"Call to undefined method OC\\Server::getConfig()","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0","version":"34.0.1.2","exception":{"Exception":"Error","Message":"Call to undefined method OC\\Server::getConfig()","Code":0,"Trace":[{"function":"__construct","class":"OCA\\OCCWeb\\Controller\\OccController","type":"->","args":["occweb",{"__class__":"OC\\AppFramework\\Http\\Request"},"user"]},{"file":"/www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/Utility/SimpleContainer.php","line":73,"function":"newInstanceArgs","class":"ReflectionClass","type":"->","args":[["occweb",{"__class__":"OC\\AppFramework\\Http\\Request"},"user"]]},{"file":"/www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/Utility/SimpleContainer.php","line":131,"function":"buildClass","class":"OC\\AppFramework\\Utility\\SimpleContainer","type":"->","args":[{"__class__":"ReflectionClass","name":"OCA\\OCCWeb\\Controller\\OccController"},["OCA\\OCCWeb\\Controller\\OccController"]]},{"file":"/www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/Utility/SimpleContainer.php","line":158,"function":"resolve","class":"OC\\AppFramework\\Utility\\SimpleContainer","type":"->","args":["OCA\\OCCWeb\\Controller\\OccController",["OCA\\OCCWeb\\Controller\\OccController"]]},{"file":"/www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/DependencyInjection/DIContainer.php","line":379,"function":"query","class":"OC\\AppFramework\\Utility\\SimpleContainer","type":"->","args":["OCA\\OCCWeb\\Controller\\OccController",true,[]]},{"file":"/www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/DependencyInjection/DIContainer.php","line":348,"function":"queryNoFallback","class":"OC\\AppFramework\\DependencyInjection\\DIContainer","type":"->","args":["OCA\\OCCWeb\\Controller\\OccController",[]]},{"file":"/www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/App.php","line":117,"function":"query","class":"OC\\AppFramework\\DependencyInjection\\DIContainer","type":"->","args":["OCA\\OCCWeb\\Controller\\OccController"]},{"file":"/www/htdocs/xxxxxx/xxxxxx/lib/private/Route/Router.php","line":324,"function":"main","class":"OC\\AppFramework\\App","type":"::","args":["OCA\\OCCWeb\\Controller\\OccController","index",{"__class__":"OC\\AppFramework\\DependencyInjection\\DIContainer"},{"_route":"occweb.occ.index"}]},{"file":"/www/htdocs/xxxxxx/xxxxxx/lib/base.php","line":1159,"function":"match","class":"OC\\Route\\Router","type":"->","args":["/apps/occweb/"]},{"file":"/www/htdocs/xxxxxx/xxxxxx/index.php","line":25,"function":"handleRequest","class":"OC","type":"::","args":[]}],"File":"/www/htdocs/xxxxxx/xxxxxx/apps/occweb/lib/Controller/OccController.php","Line":34,"message":"Call to undefined method OC\\Server::getConfig()","exception":"{\"class\":\"Error\",\"message\":\"Call to undefined method OC\\Server::getConfig()\",\"code\":0,\"file\":\"/www/htdocs/xxxxxx/xxxxxx/apps/occweb/lib/Controller/OccController.php:34\",\"trace\":\"#0 [internal function]: OCA\\OCCWeb\\Controller\\OccController->__construct('occweb', Object(OC\\AppFramework\\Http\\Request), 'user')\\n#1 /www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/Utility/SimpleContainer.php(73): ReflectionClass->newInstanceArgs(Array)\\n#2 /www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/Utility/SimpleContainer.php(131): OC\\AppFramework\\Utility\\SimpleContainer->buildClass(Object(ReflectionClass), Array)\\n#3 /www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/Utility/SimpleContainer.php(158): OC\\AppFramework\\Utility\\SimpleContainer->resolve('OCA\\\\OCCWeb\\\\Cont...', Array)\\n#4 /www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/DependencyInjection/DIContainer.php(379): OC\\AppFramework\\Utility\\SimpleContainer->query('OCA\\\\OCCWeb\\\\Cont...', true, Array)\\n#5 /www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/DependencyInjection/DIContainer.php(348): OC\\AppFramework\\DependencyInjection\\DIContainer->queryNoFallback('OCA\\\\OCCWeb\\\\Cont...', Array)\\n#6 /www/htdocs/xxxxxx/xxxxxx/lib/private/AppFramework/App.php(117): OC\\AppFramework\\DependencyInjection\\DIContainer->query('OCA\\\\OCCWeb\\\\Cont...')\\n#7 /www/htdocs/xxxxxx/xxxxxx/lib/private/Route/Router.php(324): OC\\AppFramework\\App::main('OCA\\\\OCCWeb\\\\Cont...', 'index', Object(OC\\AppFramework\\DependencyInjection\\DIContainer), Array)\\n#8 /www/htdocs/xxxxxx/xxxxxx/lib/base.php(1159): OC\\Route\\Router->match('/apps/occweb/')\\n#9 /www/htdocs/xxxxxx/xxxxxx/index.php(25): OC::handleRequest()\\n#10 {main}\"}","CustomMessage":"Call to undefined method OC\\Server::getConfig()"},"id":"6a4e499fa302b"}

[Fuseteam]

duplicate of #27

[Speeeedy66]

Fixing occweb on Nextcloud 34

Environment: Nextcloud 34.0.1, occweb app (Adphi/occweb, last released April 2025, declared compatible up to NC31). None of this is provider-specific — it applies to any Nextcloud install running occweb on NC34, on any host. Section 0 additionally applies if your hosting environment happens to run SSH in a chroot (common on many shared-hosting providers, not just one).

After upgrading to Nextcloud 34, occweb was flagged incompatible, and getting it running again turned into a four-part fix. Posting the whole chain here in case it saves someone else the same troubleshooting.

0. Background (shared/chrooted hosting only): occ over SSH failing with "data directory is invalid"

Skip this section if occ over SSH already works for you. This isn't occweb-specific, but it's a common prerequisite issue on shared hosting: many providers run the SSH session in a chroot with a different filesystem view than the web server process. If config.php has a hardcoded absolute datadirectory/tempdirectory (e.g. /var/www/vhosts/<vhost>/nc/data), the web server resolves it fine, but occ over SSH cannot find that path — resulting in:

Your data directory is invalid.
Cannot create "data" directory.

Important gotcha: don't try to "fix" this with conditional logic (file_exists()/realpath()) directly inside the datadirectory/tempdirectory lines in config.php. Nextcloud rewrites config.php on certain operations (e.g. occ maintenance:mode --on/--off), and it serializes the currently resolved value back as a hardcoded string — from whichever context (CLI or web) triggered the rewrite. Do that from CLI and you'll silently overwrite your working web-server path, breaking the entire web UI.

The safe fix: keep datadirectory/tempdirectory in config.php untouched (whatever already works for the web server), and add a separate file that Nextcloud auto-loads but never rewrites:

config/cli.config.php:

<?php
if (php_sapi_name() === 'cli') {
    if (!file_exists($CONFIG['datadirectory'])) {
        $CONFIG['datadirectory'] = realpath(__DIR__ . '/../data');
    }
    if (!file_exists($CONFIG['tempdirectory'])) {
        $CONFIG['tempdirectory'] = realpath(__DIR__ . '/../../tmp');
    }
}

Nextcloud loads every config/*.config.php after config.php and applies it, but never writes to these files itself. This survives occ calls, updates, and admin-panel saves.

1. occweb: "Call to undefined method OC\Server::getConfig()"

With CLI working, occweb's own web page still threw:

Error: Call to undefined method OC\Server::getConfig()
  at apps/occweb/lib/Controller/OccController.php:34

Nextcloud has been progressively removing legacy static OC\Server::getXYZ() facade methods in favor of DI (OC::$server->get(Interface::class)). getConfig() was apparently removed in 34, and occweb (unmaintained since April 2025) still called it directly. Every other dependency in the same constructor already used the modern pattern — this was the one leftover.

Fix — in apps/occweb/lib/Controller/OccController.php, change:

OC::$server->getConfig(),

to:

OC::$server->get(\OCP\IConfig::class),

2. occweb: blank/black screen, no input line

With the backend fixed, occweb's own page loaded but showed a black screen with no visible terminal or prompt. Browser console showed:

index.js: Uncaught ReferenceError: jQuery is not defined
term.js: Uncaught TypeError: Cannot set properties of undefined (setting 'omap')
unix_formatting.js: Uncaught TypeError: Cannot read properties of undefined (reading 'terminal')

occweb's frontend (a bundled jQuery Terminal plugin) assumes a global jQuery is already present on the page. Nextcloud 34's admin/app pages no longer load jQuery globally by default (the core UI has been moving to Vue), so occweb's own scripts failed immediately — term.js and unix_formatting.js errors were just cascading fallout from the missing jQuery global.

Fix — bundle jQuery with the app itself instead of relying on Nextcloud core to provide it:

1. Download a jQuery 3.x build and save it as apps/occweb/js/jquery.js.
2. In apps/occweb/templates/index.php, load it before the app's own scripts:

<?php
script('occweb', 'jquery');
script('occweb', 'index');
script('occweb', 'term');
script('occweb', 'unix_formatting');
style('occweb', 'style');
?>

3. occweb: request to /cmd fails with HTTP 412

After adding jQuery, the terminal rendered, but any command sent to the backend failed with:

GET .../apps/occweb/cmd  412 (Precondition Failed)

HTTP 412 in Nextcloud's AppFramework is the CSRF check (CrossSiteRequestForgeryException / StrictCookieMissingException). Nextcloud's own core JS normally wires the CSRF requesttoken into jQuery's $.ajaxSetup() automatically — but only for its own jQuery instance. Our freshly bundled, independent jQuery knew nothing about that token, so every AJAX call from occweb was missing the required header.

Fix — add a small script that wires the token into our own jQuery instance. New file apps/occweb/js/csrf.js:

(function() {
  var token = (window.OC && window.OC.requestToken)
    || document.head.getAttribute('data-requesttoken');

  if (window.jQuery && token) {
    window.jQuery.ajaxSetup({
      headers: { requesttoken: token }
    });
  }
})();

Load it right after jQuery, before the other occweb scripts:

<?php
script('occweb', 'jquery');
script('occweb', 'csrf');
script('occweb', 'index');
script('occweb', 'term');
script('occweb', 'unix_formatting');
style('occweb', 'style');
?>

Result

With changes 1–3 in place, occweb works again on Nextcloud 34, on any hosting setup. Change 0 is only needed if your occ over SSH was broken to begin with (typically a shared-hosting/chroot symptom).

Caveats

• These are manual patches to app code and to config.php-adjacent files. A future occweb update/reinstall will overwrite the js/ and Controller/ changes — keep a copy of the diffs.
• config/cli.config.php is safe from Nextcloud's own rewrites, but always worth double-checking after a major Nextcloud upgrade.
• occweb itself is unmaintained (deprecated by its author) — treat this as a stopgap, not a long-term guarantee against the next Nextcloud version breaking something else.

[Speeeedy66]

occweb unter Nextcloud 34 wieder zum Laufen bringen

Umgebung: Nextcloud 34.0.1, occweb-App (Adphi/occweb, letztes Release April 2025, deklariert kompatibel bis NC31). Das Ganze ist nicht anbieterspezifisch – es gilt für jede Nextcloud-Installation mit occweb auf NC34, unabhängig vom Hoster. Abschnitt 0 gilt zusätzlich, falls die eigene Hosting-Umgebung SSH in einem Chroot ausführt (weit verbreitet bei vielen Shared-Hosting-Anbietern, nicht nur bei einem einzelnen).

Nach dem Update auf Nextcloud 34 wurde occweb als inkompatibel markiert. Es wieder zum Laufen zu bringen, endete in einem vierteiligen Fix. Ich poste die komplette Kette hier, falls es jemand anderem dieselbe Fehlersuche erspart.

0. Hintergrund (nur bei Shared-/Chroot-Hosting): occ per SSH scheitert mit "Datenverzeichnis ist ungültig"

Diesen Abschnitt überspringen, wenn occ per SSH bei dir bereits funktioniert. Das ist nicht occweb-spezifisch, aber ein häufiges Vorab-Problem bei Shared-Hosting: Viele Anbieter führen die SSH-Sitzung in einem Chroot aus, das eine andere Dateisystem-Sicht hat als der Webserver-Prozess. Wenn config.php einen fest einprogrammierten absoluten Pfad für datadirectory/tempdirectory enthält (z. B. /var/www/vhosts/<vhost>/nc/data), löst der Webserver das problemlos auf, aber occ per SSH findet diesen Pfad nicht – mit der Folge:

Your data directory is invalid.
Cannot create "data" directory.

Wichtige Falle: Versucht nicht, das mit bedingter Logik (file_exists()/realpath()) direkt in den datadirectory/tempdirectory-Zeilen der config.php zu "reparieren". Nextcloud schreibt die config.php bei bestimmten Vorgängen neu (z. B. occ maintenance:mode --on/--off) und serialisiert dabei den aktuell aufgelösten Wert als festen String zurück – aus welchem Kontext (CLI oder Web) auch immer der Schreibvorgang ausgelöst wurde. Macht man das von der CLI aus, überschreibt man damit stillschweigend den funktionierenden Webserver-Pfad und zerschießt die gesamte Weboberfläche.

Die sichere Lösung: datadirectory/tempdirectory in der config.php unangetastet lassen (so, wie es für den Webserver bereits funktioniert), und stattdessen eine separate Datei anlegen, die Nextcloud automatisch lädt, aber nie selbst überschreibt:

config/cli.config.php:

<?php
if (php_sapi_name() === 'cli') {
    if (!file_exists($CONFIG['datadirectory'])) {
        $CONFIG['datadirectory'] = realpath(__DIR__ . '/../data');
    }
    if (!file_exists($CONFIG['tempdirectory'])) {
        $CONFIG['tempdirectory'] = realpath(__DIR__ . '/../../tmp');
    }
}

Nextcloud lädt jede Datei config/*.config.php nach der config.php und wendet sie an, schreibt diese Dateien aber selbst niemals. Das übersteht occ-Aufrufe, Updates und Speichervorgänge im Admin-Panel.

1. occweb: "Call to undefined method OC\Server::getConfig()"

Nachdem die CLI funktionierte, warf occwebs eigene Web-Seite immer noch:

Error: Call to undefined method OC\Server::getConfig()
  at apps/occweb/lib/Controller/OccController.php:34

Nextcloud entfernt seit einiger Zeit schrittweise veraltete, statische OC\Server::getXYZ()-Facade-Methoden zugunsten von Dependency Injection (OC::$server->get(Interface::class)). getConfig() wurde offenbar in Version 34 entfernt, und occweb (seit April 2025 unmaintained) rief sie noch direkt auf. Jede andere Abhängigkeit im selben Konstruktor nutzte bereits das moderne Muster – das war der letzte übrig gebliebene Altlast-Aufruf.

Fix – in apps/occweb/lib/Controller/OccController.php diese Zeile:

OC::$server->getConfig(),

ändern zu:

OC::$server->get(\OCP\IConfig::class),

2. occweb: schwarzer Bildschirm, keine Eingabezeile

Mit repariertem Backend lud occwebs Seite zwar, zeigte aber einen schwarzen Bildschirm ohne sichtbares Terminal oder Eingabeaufforderung. Die Browser-Konsole zeigte:

index.js: Uncaught ReferenceError: jQuery is not defined
term.js: Uncaught TypeError: Cannot set properties of undefined (setting 'omap')
unix_formatting.js: Uncaught TypeError: Cannot read properties of undefined (reading 'terminal')

occwebs Frontend (ein mitgeliefertes jQuery-Terminal-Plugin) geht davon aus, dass auf der Seite bereits ein globales jQuery vorhanden ist. Die Admin-/App-Seiten von Nextcloud 34 laden jQuery standardmäßig nicht mehr global (die Kern-Oberfläche wandert zunehmend zu Vue), weshalb occwebs eigene Skripte sofort scheiterten – die Fehler in term.js und unix_formatting.js waren nur Folgeschäden des fehlenden jQuery-Globals.

Fix – jQuery direkt mit der App mitliefern, statt sich auf den Nextcloud-Kern zu verlassen:

1. Einen jQuery-3.x-Build herunterladen und als apps/occweb/js/jquery.js speichern.
2. In apps/occweb/templates/index.php vor den eigentlichen App-Skripten laden:

<?php
script('occweb', 'jquery');
script('occweb', 'index');
script('occweb', 'term');
script('occweb', 'unix_formatting');
style('occweb', 'style');
?>

3. occweb: Anfrage an /cmd scheitert mit HTTP 412

Nachdem jQuery ergänzt war, baute sich das Terminal zwar auf, aber jeder ans Backend gesendete Befehl scheiterte mit:

GET .../apps/occweb/cmd  412 (Precondition Failed)

HTTP 412 ist im AppFramework von Nextcloud der CSRF-Check (CrossSiteRequestForgeryException / StrictCookieMissingException). Nextclouds eigenes Kern-JavaScript verdrahtet den CSRF-requesttoken normalerweise automatisch in jQuerys $.ajaxSetup() – aber nur für seine eigene jQuery-Instanz. Unser frisch mitgeliefertes, unabhängiges jQuery wusste nichts von diesem Token, weshalb jedem AJAX-Aufruf von occweb der erforderliche Header fehlte.

Fix – ein kleines Skript ergänzen, das den Token in unsere eigene jQuery-Instanz einspeist. Neue Datei apps/occweb/js/csrf.js:

(function() {
  var token = (window.OC && window.OC.requestToken)
    || document.head.getAttribute('data-requesttoken');

  if (window.jQuery && token) {
    window.jQuery.ajaxSetup({
      headers: { requesttoken: token }
    });
  }
})();

Direkt nach jQuery laden, vor den übrigen occweb-Skripten:

<?php
script('occweb', 'jquery');
script('occweb', 'csrf');
script('occweb', 'index');
script('occweb', 'term');
script('occweb', 'unix_formatting');
style('occweb', 'style');
?>

Ergebnis

Mit den Änderungen 1–3 funktioniert occweb wieder unter Nextcloud 34, auf jedem Hosting-Setup. Änderung 0 ist nur nötig, wenn occ per SSH von vornherein schon kaputt war (typischerweise ein Shared-Hosting-/Chroot-Symptom).

Zu beachten

• Das sind manuelle Patches am App-Code und an config.php-nahen Dateien. Ein künftiges occweb-Update oder eine Neuinstallation überschreibt die Änderungen in js/ und Controller/ – am besten die Diffs irgendwo aufbewahren.
• config/cli.config.php ist vor Nextclouds eigenen Schreibvorgängen sicher, aber nach einem großen Nextcloud-Update trotzdem einmal gegenprüfen.
• occweb selbst ist unmaintained (vom Entwickler als deprecated markiert) – das hier ist eher eine Übergangslösung als eine dauerhafte Garantie gegen künftige Brüche durch neue Nextcloud-Versionen.

[Fuseteam]

@Speeeedy66 please don't post unfiltered outputs from AI bots— there is already a pull request for this: #26

[Speeeedy66]

@Fuseteam Sorry, I just wanted to share that. It works perfectly in my setup.

[rodnand]

Especially the no. 0 was really helpful for me because until the last update occweb worked for me but occ over ssh didn't. With this cli.config.php both are working now on my Nexcloud instance on a webspace without root access. So I think it's a good summary for amateurs like me to unterstand the problem and fix it for the moment.