Your web server is not properly set up to resolve "/ocm-provider/"


How did you setup Nextcloud? Are you running Nextcloud behind a reverse proxy? Can you post a link to your output of nginx -T (don‘t Post it entirely here, because it will be a lot of text!).



Hi Bernie_O,

Thank you for your prompt reply.

Here below some output lines from the command “nginx -T”.

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

configuration file /etc/nginx/nginx.conf:

user www-data;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/;
events {
worker_connections 1024;
multi_accept on;
use epoll;
http {
server_names_hash_bucket_size 64;
upstream php-handler {
server unix:/run/php/php7.3-fpm.sock;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
include /etc/nginx/mime.types;
#include /etc/nginx/proxy.conf;
include /etc/nginx/ssl.conf;
include /etc/nginx/header.conf;
include /etc/nginx/optimization.conf;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] “$request” ’
'$status $body_bytes_sent “$http_referer” ’
'"$http_user_agent" “$http_x_forwarded_for” ’
'"$host" sn="$server_name" ’
'rt=$request_time ’
'ua="$upstream_addr" us="$upstream_status" ’
'ut="$upstream_response_time" ul="$upstream_response_length" ’
‘cs=$upstream_cache_status’ ;
access_log /var/log/nginx/access.log main;
sendfile on;
send_timeout 3600;
tcp_nopush on;
tcp_nodelay on;
open_file_cache max=500 inactive=10m;
open_file_cache_errors on;
keepalive_timeout 65;
reset_timedout_connection on;
server_tokens off;
resolver valid=30s;
resolver_timeout 5s;
include /etc/nginx/conf.d/*.conf;

configuration file /etc/nginx/conf.d/nextcloud.conf:

server {
listen 80;
listen [::]:80;
server_name <my_fqdn>;
# enforce https
return 301 https://$server_name$request_uri;

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name <my_fqdn>;

# Use Mozilla's guidelines for SSL/TLS settings
# NOTE: some settings below might be redundant
ssl_certificate /etc/letsencrypt/live/<my_fqdn>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<my_fqdn>/privkey.pem;

# Add headers to serve security related headers
# Before enabling Strict-Transport-Security headers please read into this
# topic first.
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy no-referrer;

# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;

# Path to the root of your installation
root /var/www/;

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;

# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
# rewrite ^/.well-known/host-meta /nextcloud/public.php?service=host-meta
# last;
#rewrite ^/.well-known/host-meta.json
# /nextcloud/public.php?service=host-meta-json last;

# The following rule is only needed for the Social app.
# Uncomment it if you're planning to use this app.
# rewrite ^/.well-known/webfinger /nextcloud/public.php?service=webfinger last;

location = /.well-known/carddav {
    return 301 $scheme://$host/nextcloud/remote.php/dav;

location = /.well-known/caldav {
    return 301 $scheme://$host/nextcloud/remote.php/dav;

location /.well-known/acme-challenge { }

location ~ ^/(?:ocm-provider|ocs-provider).* {
    rewrite ^ /nextcloud$request_uri;

location ^~ /nextcloud {

    # set max upload size
    client_max_body_size 10240M;
    # turns out the optimization conf already set the fast buffer size so I just nixed that from my conf
    #fastcgi_buffers 64 4K;

    # Enable gzip but do not remove ETag headers
    gzip on;
    gzip_vary on;
    gzip_comp_level 4;
    gzip_min_length 256;
    gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
    gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/ application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

    # Uncomment if your server is build with the ngx_pagespeed module
    # This module is currently not supported.
    #pagespeed off;

    location /nextcloud {
        rewrite ^ /nextcloud/index.php$request_uri;

    location ~ ^\/nextcloud\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
        deny all;

    location ~ ^\/nextcloud\/(?:\.|autotest|occ|issue|indie|db_|console) {
        deny all;

    location ~ ^\/nextcloud\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|ocm-provider\/.+)\.php(?:$|\/) {
        fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS on;
        #Avoid sending the security headers twice
        fastcgi_param modHeadersAvailable true;
        fastcgi_param front_controller_active true;
        fastcgi_pass php-handler;
        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;

    location ~ ^\/nextcloud\/(?:ocs-provider|ocm-provider)(?:$|\/) {
        return 301 $scheme://$host/nextcloud/ocs-provider/;
        return 301 $scheme://$host/nextcloud/ocm-provider/;
        #return 301 https://$server_name$request_uri;
        try_files $uri/ =404;
        index index.php;

    location ~ ^\/nextcloud\/(?:updater|ocs-provider|ocm-provider)(?:$|\/) {
        try_files $uri/ =404;
        index index.php;

I am quite sure it could be improved to avoid the error message :slight_smile:

Thank you again.
Best Regards,



Delete that block entirely:

It is wrong and doomed to fail (requests for oc(m|s)-provider.* get always redirected to /nextcloud/ocs-provider/$)!



Hi Bernie_O,

Following your last suggestion, I no longer have the error message. Great! :grinning:

Thank you so much.
Best Regards,

1 Like


Redirect 301 /ocm-provider/ /nextcloud/ocm-provider/
Redirect 301 /ocs-provider/ /nextcloud/ocs-provider/
to the end of /etc/apache2/sites-available/nextcloud.conf and restarting apache2 (service apache2 restart) worked for me!


1 Like


Was anyone able to find a real solution on Apache2? I tried both the rewrite rule and redirect rule and still the error persists.



A .htaccess file only affects the directory it’s placed in as well as all subdirs. Hence adding any options to the .htaccess in your subdir won’t affect any requests outside that folder (e.g. /ocm-provider).

@zamarax do you have a .htaccess in your webroot possibly overwriting your virtualhost.conf?



Given that the issue occurs for those of us who have Nextcloud installed in a subdirectory of our root web, why didn’t this work?

I did this as root on my Synology NAS:

mkdir /volume1/web/ocs-providers
mount --bind /volume1/web/nextcloud/ocs-providers /volume1/web/ocs-providers

I did the same with ocm-providers

volume1 is where everything lives on a Synology NAS with one volume.

It made no difference. Why?



On openSUSE leap 42.3 , Apache, PHP 7 upgrade to 15.0.5 from 15.0.4.
I tried following combination in the nectcloud.conf in the folder /etc/httpd/conf.d
But nothing work :frowning:

Redirect 301 /ocm-provider/ /srv/www/htdocs/nextcloud/ocm-provider/
Redirect 301 /ocs-provider/ /srv/www/htdocs/nextcloud/ocs-provider/

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

Redirect 301 /ocm-provider https://.de/srv/www/htdocs/nextcloud/ocm-provider/
Redirect 301 /ocs-provider https://.de/srv/www/htdocs/nextcloud/ocs-provider/

Alias /ocm-provider “/srv/www/htdocs/nextcloud/ocm-provider/”
Alias /ocs-provider “/srv/www/htdocs/nextcloud/ocs-provider/”



There are several fixes suggested in this thread. Thanks all.

But two questions:

  1. What are ocm-provider and ocs-provider? These are new to me. I’m familiar with .well-known dav links, which are still just suggestions (as things work just fine without those links), but I haven’t yet found an explanation of what these two are used for.

  2. Why introduce this new thing in a release version? At a minimum, I’d think release (third number in the dotted versions) would be meant for bug fixes and security fixes, not for new material like this. That (in many semantic versioning uses) is reserved for at lowest a minor (15.x) and depending on its severity a major version.

My nextcloud is working just fine without this, and unfortunately since I’m using traefik, I won’t be able to fix this (or .well-known), so I don’t see the benefit of doing this. So why should I worry about this?



Apparently something to do with open collaboration between cloud providers and with apps. Reading it troubles me that not having things set up correctly could have implications down the road. Hopefully the Nextcloud devs are aware of the issue which seems to be affecting Nextcloud users across a whole range of installations including basic, completely normal Linux installs.



@Shadow, I do but it isn’t overwriting, as I can make other exclusive entries in my .htaccess file in this subdirectory and those are working fine.



I suspect that there is no solution for Apache. I’ve tried all the fixes suggested, to no avail. That’s two hours wasted.

I think the error messages are the error.

I have searched for any reference to ocs-provider or ocm-provider in the latest version of Nextcloud, and they all seem to be specific to Nginx.

Rather irritating, as I have no intention of using any server federation in any case.

1 Like


I see, perhaps they will fix it in the next release as apache is still a larger base then nginix.



Same problem for me with apache and nextcloud in a folder on a machine behind a reverse proxy.

I suspect some bug in nextcloud, since, after applying the rewrite rules, I get a json from ocs-provider, but the url in this json are missing a part of my path.

"endpoints": {
    "store": "/ocs/v2.php/privatedata/setattribute",

instead of

"endpoints": {
    "store": "/MYPATH/ocs/v2.php/privatedata/setattribute",


It worked for me, Thanks.



In apache like many have mentioned you need to add the redirect rules to the root .htaccess (or .conf). You also “need” to add empty folders in root to avoid 404 in many cases



Thanks man, that worked like a charm!



On my Synology NAS I have /volume1/web then in the web folder I have my nextcloud installation folder. Which is the folder you call ‘the root’? I have tried creating a .htaccess folder containing the rewrite lines in /volume1/web but it has no effect. The .htaccess file in /volume1/web/nextcloud contains lines like this:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} DavClnt
RewriteRule ^$ /remote.php/webdav/ [L,R=302]
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^.well-known/host-meta /public.php?service=host-meta [QSA,L]
RewriteRule ^.well-known/host-meta.json /public.php?service=host-meta-json [QSA,$
RewriteRule ^.well-known/webfinger /public.php?service=webfinger [QSA,L]
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]
RewriteCond %{REQUEST_URI} !^/.well-known/(acme-challenge|pki-validation)/.*
RewriteRule ^(?:.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

Adding the ocm and ocs rewrite rules has no effect here either - and there is this line right at the end of the file:




The root folder is the one that points to assuming you have as your nextcloud address

Den fre 8 mars 2019 19:15Phillip Deackes via Nextcloud community skrev: