With Nextcloud update: "Not properly set up to resolve “/ocm-provider/” and “/ocs-provider/” on NGINX server

I use Apache2 as my web server, and it has been fine until the update from 27.1.1 to 27.1.2. It appears that the file ocm-provider is no longer provided, I tried to copy a copy from 27.1.1 but that made no difference. From reading I think that it is something to do with .htaccess but I have NO CLUE what to change or add

My current .htaccess is


SetEnvIfNoCase ^Authorization$ “(.+)” XAUTHORIZATION=$1
RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION

SetEnvIfNoCase Authorization “(.+)” HTTP_AUTHORIZATION=$1

SetEnvIfNoCase ^Authorization$ “(.+)” XAUTHORIZATION=$1
RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION

# Add security and privacy related headers
# Avoid doubled headers by unsetting headers in "onsuccess" table,
# then add headers to "always" table: https://github.com/nextcloud/server/pull/19002
Header onsuccess unset Referrer-Policy
Header always set Referrer-Policy "no-referrer"

Header onsuccess unset X-Content-Type-Options
Header always set X-Content-Type-Options "nosniff"

Header onsuccess unset X-Frame-Options
Header always set X-Frame-Options "SAMEORIGIN"

Header onsuccess unset X-Permitted-Cross-Domain-Policies
Header always set X-Permitted-Cross-Domain-Policies "none"

Header onsuccess unset X-Robots-Tag
Header always set X-Robots-Tag "noindex, nofollow"

Header onsuccess unset X-XSS-Protection
Header always set X-XSS-Protection "1; mode=block"

SetEnv modHeadersAvailable true

Add cache control for static resources

<FilesMatch “.(css|js|mjs|svg|gif|png|jpg|ico|wasm|tflite)$”>
<If “%{QUERY_STRING} =~ /(^|&)v=/”>
Header set Cache-Control “max-age=15778463, immutable”

Header set Cache-Control “max-age=15778463”

Let browsers cache WOFF files for a week

<FilesMatch “.woff2?$”>
Header set Cache-Control “max-age=604800”

php_value mbstring.func_overload 0
php_value default_charset ‘UTF-8’
php_value output_buffering 0

SetEnv htaccessWorking true

AddType image/svg+xml svg svgz AddType application/wasm wasm AddEncoding gzip svgz # Serve ESM javascript files (.mjs) with correct mime type AddType text/javascript js mjs DirectoryIndex index.php index.html ModPagespeed Off 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 ^ocm-provider/?$ /index.php [QSA,L] RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]

AddDefaultCharset utf-8
Options -Indexes


ErrorDocument 403 /nextcloud/index.php/error/403
ErrorDocument 404 /nextcloud/index.php/error/404


I suspect it is the rewrite rules I need to add/alter

PHP 8.1
Apapche2 2.4.52
Ubuntu 22.04

Any help gratefully received

Yeah, I would but that sample for subdir has a handful of errors in it, e.g.
location /nextcloud {
try_files $uri $uri/ /nextcloud/index.php$request_uri;
fails with "nginx: [emerg] location “/nextcloud” is outside location “/nextcloud/”’

Should probably be:
location ~ /nextcloud {

I have the same problem on apache2 after updating nextcloud from 27.1.1 to 27.1.2, before that I never had this problem

@fuzunspm I’m having the same issue and opened a different thread:


I found out how to solve the problem on my installation.
I was missing the following in my Nextcloud .conf file for apache2:

  <Directory /var/www/html/nextcloud/>
    Require all granted
    AllowOverride All
    Options FollowSymLinks MultiViews

    <IfModule mod_dav.c>
      Dav off
1 Like

There is much chit-chat about this stuff in various nextcloud github issues related to upgrading to the latest 27.1.2 version. There seems to be a problem.

I’m running an apache server with nextcloud in a sub-directory. The fix in this comment solved the problem for me:

TL;DR - in the .htacces file found in your nextcloud root, drop the front slash of the index.php part of this line:

RewriteRule ^ocm-provider/?$ index.php [QSA,L]

I suspect you could also ignore the warning and it will be fixed in the next release of nextcloud.

Thank you… That worked for me

so i managed to fix this on my instance, going line by line and testing the “Nextcloud in a subdir of the NGINX webroot” sample (fixing errors from that sample as well) against my older install.
I did need to clear my browser cache as mentioned in another thread.
When I cleared cache in between each ‘test’ I was able to get the Nextcloud security check to pass successfully with:



location ~ ^/(?:updater|oc[ms]-provider)(?:$|/) {
            try_files $uri/ =404;
            index index.php;

For me also the same issue at Nginx & php 8.2 fpm, i tried all versions here & in other threads, nothing works
All caches cleared also at server level with redis & Memcache - always the same errors

Hopefully not the next error with webfinger and nodeinfo which cannot be resolved

I also had the issue never before

1 Like

this seems to have returned since version 27.1.2 for me. Had it resolved for 27.0.2 earlier.

edit: when upgrading to 27.1.2 I had to revert the fix described above: “Not properly set up to resolve “/ocm-provider/” and “/ocs-provider/” on NGINX server - #8 by trendzetter

I had the same warning, but only after upgrading from version 27.1.0 to version 27.1.2:

Your web server is not properly set up to resolve "/ocm-provider/". This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in ".htaccess" for Apache or the provided one in the documentation for Nginx at it's [documentation page ↗](https://docs.nextcloud.com/server/27/go.php?to=admin-nginx). On Nginx those are typically the lines starting with "location ~" that need an update.
Well, the reason is simple: Unlike in earlier versions, where all the above fixes did the trick, there is no /ocm-provider folder any more in Nextcloud 27.1.2!
I guess this error message is actually a bug, but let’s see what you think!


I really don’t get why this is suddenly an issue. I mean if the ocm-provider directory isn’t there anymore there is nothing to resolve to, isn’t it? Also according to the example config in the documentation it was never really necessary to add any specific rules for subfolders in the first place…

 # Specify how to handle directories -- specifying `/index.php$request_uri`
    # here as the fallback means that Nginx always exhibits the desired behaviour
    # when a client requests a path that corresponds to a directory that exists
    # on the server. In particular, if that directory contains an index.php file,
    # that file is correctly served; if it doesn't, then the request is passed to
    # the front-end controller. This consistent behaviour means that we don't need
    # to specify custom rules for certain paths (e.g. images and other assets,
    # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
    # `try_files $uri $uri/ /index.php$request_uri`
    # always provides the desired behaviour.
    index index.php index.html /index.php$request_uri;

Same goes for Apache, where it is even easier, Just use the following config from the official documentation and the included .htaccess files should take care of everything for you:

  <Directory /var/www/nextcloud/>
    Require all granted
    AllowOverride All
    Options FollowSymLinks MultiViews

    <IfModule mod_dav.c>
      Dav off

I never had any error messages like this for years, and all I ever did was upgrading Nextcloud with the integrated updater, and there was never even a single reason to adjust my web server config


Use the configurations from the docs unless you have a specific reason to use a different configuration, and everything should just work.

If it still doesn’t work, or if you have a special configuration for whatever reason, maybe because you’re running it behind a reverse proxy or on a web hosting platform etc, open a new thread and describe your setup in detail, and post your web server and reverse proxy configs.

Without detailed information about your setup no one can actually help you, and you just end up pasting someone else’s config snippets into your web server configuration that may work for that person’s particular configuration, but probably won’t work for yours.

Since this topic is the top result on google when searching I’ll add this here:

If anyone is crazy enough to be running nextcloud with lighttpd like me, I fixed this on 27.1.2 by changing the old ocm-provider rewrite rule to the following (select the one that applies to you):

# For nextcloud on document root
url.rewrite-once += (
        "^/ocm-provider/?$" => "/index.php?$1"

# For nextcloud on a sub-directory
url.rewrite-once += (
        "^/nextcloud/ocm-provider/?$" => "/nextcloud/index.php?$1"

Edit: More accurate solution.

Bei mir ließ sich das Problem mit Nextcloud Bordmitteln beheben:
php occ config:system:set htaccess.RewriteBase --value=‘/’
php occ maintenance:update:htaccess

Ja, das gilt aber nur für apache2, in diesem (veralteten) Thread, ging es um nginx :wink:

I installed v26 with apk on alpine with nginx php-fpm, everything seems to be working, except for the ocm-provider. I have followed all of the nginx related fixes. I looked in the nextcloud folder, and there’s simply.no.ocm-provider folder.

webfinger and nodeinfo still show as issue in nextcloud, and network info says they couldn’t connect, but curl on those locations had no issue so I’d say this is a jquery/ajax problem

Lösung für Nextcloud 28.0.1, Apache2 und Nginx-Proxymanager:

Gehe im Nginx-Proxymanager unter Edit Host / Advanced und paste folgende Zeilen:

location ^~ /.well-known {
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
location ^~ /.well-known { return 301 /index.php$uri; }
try_files $uri $uri/ =404;
location = /ocm-provider/ {return 301 /index.php/ocm-provider;}


Wobei dies hier die entscheidende Zeile ist:
location = /ocm-provider/ {return 301 /index.php/ocm-provider;}

Muß in der Config unter dem besagten Block eingefügt werden.

Das hat auch bei mir geklappt, danke für Deinen Support und Hilfe

Thank you very much for your solution.