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

ℹ️ Support
, ,
22

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

23

Greetings!
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!
C.

24

@all

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
    </IfModule>
  </Directory>

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

Conclusion:

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.

25

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.

26

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

27

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

28

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

29

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;}

3 Likes
30

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.

31

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

32

Thank you very much for your solution.

33

Aktuell habe ich Ubuntu 24.04 LTS, PHP 8.2 und Nextcloud 8 ( 29.0.5) mit dem NginxProxy Manager.

Auch hier war der Code im Nginx die Lösung des Problems:

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;}