Welchen Zweck haben die Ordner oc?-provider?

[segh]

Welche Umleitung aus den verschiedenen Empfehlungen in anderen Threads ich auch anwende, die Meldung “Dein Webserver ist nicht ordnungsgemäß für die Auflösung von “/ocm-provider/” eingerichtet.” (resp. ocs-provider) verschwindet nicht.
Wozu sind die beiden Ordner überhaupt zuständig? In beiden ist nur eine Datei index.php.

Meine NextCloud ist eine von 15 an bis jetzt aktualisierte.

Meine Annahme das es mit dem ausgelagerten data-Ordner (siehe anderer Thread) zu tun haben könnte scheint mir nicht mehr schlüssig.

[devnull]

Kannst du weitere Details posten? Die fehlerhafte Umleitung könnte sowohl auf deinem Webserver als auch in der .htaccess von Nextcloud entstanden sein. Wofür die Ordner sind, weiß ich auch nicht. Würde ich aber auch gerne wissen. Ich kann mir schon vorstellen, dass es an der Lokation des data-Ordners liegen kann.

[segh]

Klar was brauchst Du?
Die rewrite-Passagen aus der .htaccess aus dem nextcloud Ordner habe ich unten beigelegt.

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT} DavClnt
  RewriteRule ^$ /remote.php/webdav/ [L,R=302]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
  RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

AddDefaultCharset utf-8
Options -Indexes
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 /
ErrorDocument 404 /
<IfModule mod_rewrite.c>
  Options -MultiViews
  RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]
  RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]
  RewriteCond %{REQUEST_FILENAME} !\.(css|js|svg|gif|png|html|ttf|woff2?|ico|jpg|jpeg|map|webm|mp4|mp3|ogg|wav|wasm|tflite)$
  RewriteCond %{REQUEST_FILENAME} !/core/ajax/update\.php
  RewriteCond %{REQUEST_FILENAME} !/core/img/(favicon\.ico|manifest\.json)$
  RewriteCond %{REQUEST_FILENAME} !/(cron|public|remote|status)\.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v(1|2)\.php
  RewriteCond %{REQUEST_FILENAME} !/robots\.txt
  RewriteCond %{REQUEST_FILENAME} !/(ocm-provider|ocs-provider|updater)/
  RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
  RewriteCond %{REQUEST_FILENAME} !/richdocumentscode(_arm64)?/proxy.php$
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /
  <IfModule mod_env.c>
    SetEnv front_controller_active true
    <IfModule mod_dir.c>
      DirectorySlash off
    </IfModule>
  </IfModule>
</IfModule>

In der .htaccess hatte ich noch keine Änderungen vorgenommen. In der vhost.conf vom apache habe ich alle Änderungen die ich zu diesem Thema gemacht hatte wieder zurückgenommen.

[segh]

Ok, ich weiß immer noch nicht welchen Zweck diese Verzeichnisse haben, aber ich habe die Ursache gefunden …
Also für die Akten:
Mit einem Update (zw. 24.0.1-24.0.3) wurde die …/apache2/conf.d/nextcloud.conf geändert.

Dort stand nun:

Redirect 301 /ocm-provider/ /nextcloud/ocm-provider/
Redirect 301 /ocs-provider/ /nextcloud/ocs-provider/

In (m)einer apache-vhost Umgebung macht so etwas natürlich wenig Sinn … zumindest wenn document-root …/ ist (und nicht …/nextcloud)

Kaum habe ich die neuen Zeilen auskommentiert, schon wird oc(m|s)-provider wieder gefunden.

Ich leg’ mich wieder hin …

[devnull]

Danke, dass du deine Lösung geschrieben hast. Aber ich glaube kaum, dass bei einem Nextcloud-Upgrade Änderungen in der Apache2-Konfiguration vorgenommen werden (das wäre wirklich schlimm). Bist du wirklich sicher, dass sich in der Apache2-Konfiguration was geändert hat? Oder war vielleicht der Wert vorher schon da und nun durch eine Änderung in Nextcloud passt die Konfiguration nicht mehr? Schon komisch. Aber es gibt so einige Dinge bei Nextcloud, die man vielleicht gar nicht verstehen will.

[segh]

Es gibt (hier) eine Datei “/etc/apache2/conf.d/nextcloud.conf” die definitiv von Nextcloud ist. Und die wurde vom Upgrade angepasst.

Und da ich hier kurze URL verwende (wie in der Doku beschrieben), also (https://<my.fqdn.tld>/) und nicht https://<my.fqdn.tld>/nexcloud/) passt die Umleitung in der nextcloud.conf nicht.

Ich war nur der Meinung das ich alle include *.conf deaktiviert hätte …
Erst als ich dann stumpf direkt in der nextcloud.conf die Umleitung auskommentiert hatte, lief’s.

[devnull]

@segh

Es gibt (hier) eine Datei “/etc/apache2/conf.d/nextcloud.conf” die definitiv von Nextcloud ist.

Wirklich? Ich finde Nextcloud sollte nicht in den Konfigurationen der virtuellen Webserver des Apache2 ändern auch wenn der Benutzer www-data ist. Glauben kann ich das immer noch nicht.

[bb77]

@devnull

Glauben kann ich das immer noch nicht.

Ich auch nicht. Nextcloud bzw. www-data kann gar nicht nach /etc/apache2/… schreiben. Bei mir hat da jedenfalls nur root Zugriff. Die Config wurde irgendwann mal von irgendjemandem erstellt…

…oder von irgendwas:

@segh Nutzt du irgend ein Web Admin Panel wie Webmin, ISPconfig oder Plesk…?