[solved] Issues after update to NC 27.1.2: not properly set up to resolve /nextcloud/ocm-provider/

Hi community,

After updating my NC to version 27.1.2 i see the following issue in the administration → overview

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

Looking at the linked documentation page under this error-message, all I see are information regarding NGNIX. Thats useless for me, as I am using Apache2.
On the previuous version I was running before (don’t remember the version, it was some V27 as well) I did not face this issue. The server itself has not been modified in any way.

So whats that ??? I would be very very thankfull for a hint regarding this and how I can solve this.

Thank you in advance :upside_down_face:

Please use the search function, there are already a zillion posts on the subject in multiple threads.

If you still need help after reading them, please describe your setup in the detail and post your webserver configuration etc… See also my little rant about this here , especially this.

Thanks for this hint, but these snips are already contained since I installed NC. Which description of my setup do you need ?

It’s PHP8.2-fpm on Ubuntu 22.04.3 LTS, Apache2

Just added the following snip to my config:

Redirect 301 /ocm-provider/ /index.php/ocm-provider/

Did not solve the issue of course…

My configuration, not put in .htaccess but inside apache (what was always working flawless since years) is as follows:

Alias /nextcloud "/var/www/clients/client2/web14/web/nextcloud/"

<Directory /var/www/clients/client2/web14/web/nextcloud/>
  Require all granted
  AllowOverride All
  Options FollowSymLinks MultiViews

  <IfModule mod_dav.c>
    Dav off
<IfModule mod_headers.c>
     Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteRule ^/\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^/\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
 Redirect 301 /ocm-provider/ /index.php/ocm-provider/
RewriteRule ^/\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
  RewriteRule ^/\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]

Also after deleting my browsers cache these errors are still present. So now I did everything I can find but the issue is still in plkace

When I browse to https://mynestcloud.tld/index.php/ocm-provider I get the following json-based content:

enabled	true
apiVersion	"1.0-proposal1"
endPoint	"https://cloud.domain.de/nextcloud/index.php/ocm"
name	"file"
0	"user"
1	"group"
webdav	"/public.php/webdav/"

I even do not know for what this might be usefull honestly.

But I do not see something like ocm in my directorytree. But I see ocs:

dir -all provides:

drwxr-xr-x 14 web14 client2    4096 Okt 15 10:18 .
drwx--x--x  5 web14 client2    4096 Dez 14  2022 ..
drwxr-xr-x 45 web14 client2    4096 Okt 15 08:38 3rdparty
drwxr-xr-x 75 web14 client2    4096 Okt 15 08:58 apps
-rw-r--r--  1 web14 client2   23796 Okt  5 10:47 AUTHORS
-rw-r--r--  1 web14 client2    1283 Okt  5 10:47 composer.json
-rw-r--r--  1 web14 client2    3140 Okt  5 10:47 composer.lock
drwxr-xr-x  2 web14 client2    4096 Okt 15 08:56 config
-rw-r--r--  1 web14 client2    4095 Okt  5 10:47 console.php
-rw-r--r--  1 web14 client2   34520 Okt  5 10:47 COPYING
drwxr-xr-x 24 web14 client2    4096 Okt 15 08:38 core
-rw-r--r--  1 web14 client2    6317 Okt  5 10:47 cron.php
drwxrwx---  9 web14 client2    4096 Mär 18  2023 data
drwxr-xr-x  2 web14 client2   16384 Okt 15 08:38 dist
-rw-r--r--  1 web14 client2    3325 Okt 15 08:38 .htaccess
-rw-r--r--  1 web14 client2     156 Okt  5 10:47 index.html
-rw-r--r--  1 web14 client2    3456 Okt  5 10:47 index.php
drwxr-xr-x  6 web14 client2    4096 Okt 15 08:38 lib
-rw-r--r--  1 web14 client2     283 Okt  5 10:47 occ
drwxr-xr-x  2 web14 client2    4096 Okt 15 08:38 ocs
drwxr-xr-x  2 web14 client2    4096 Okt 15 08:38 ocs-provider
-rw-r--r--  1 web14 client2    6342 Okt  5 10:47 package.json
-rw-r--r--  1 web14 client2 1849208 Okt  5 10:47 package-lock.json
-rw-r--r--  1 web14 client2    3187 Okt  5 10:47 public.php
-rw-r--r--  1 web14 client2    5597 Okt  5 10:47 remote.php
drwxr-xr-x  4 web14 client2    4096 Okt 15 08:38 resources
-rw-r--r--  1 web14 client2      26 Okt  5 10:47 robots.txt
-rw-r--r--  1 web14 client2    2452 Okt  5 10:47 status.php
drwxr-xr-x  3 web14 client2    4096 Okt 15 08:38 themes
drwxr-xr-x  2 web14 client2    4096 Okt 15 08:38 updater
-rw-r--r--  1 web14 client2     318 Okt 15 08:54 .user.ini
-rw-r--r--  1 web14 client2     403 Okt  5 10:53 version.php

I identified the cause by my own now - due to the update .htaccess has been enriched with trashy code, not matching my setup at all :rage: (why whjy why) :pensive:

Code was

<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 ^ocm-provider/?$ /index.php [QSA,L]
  RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]

But in fact code has to be like this:

<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 /nextcloud/remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /nextcloud/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) /nextcloud/index.php [QSA,L]
  RewriteRule ^ocm-provider/?$ /nextcloud/index.php [QSA,L]
  RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]

It seems like .htaccess overwrote the host settings definded with apache host config. Ok, that was expectable, because due to “AllowOverride” the .htaccess wins - of course.

However - solved for me :grinning:

I wish that this maybe helps other people as well :black_heart:

1 Like

Because that way, people like me, who have a “standard” setup and let the .htaccess file handle everythig, can just update without having to touch anything. :wink:

However, I’m glad you figured it out. :slight_smile:

1 Like

Yes, thats indeed nice for people like you - I totally begrudge you this privilege :black_heart:
And, beside, this has nothing to do with handling by .htaccess or handling by host-config.

If a hostconfig contains the following snip …

AllowOverride All

… then the .htaccessfile wins of course - always.

I think that that you advantage (and my disadvantage) is much more caused by the fact that you installed NC on root directory - am I correct ? I am quite sure that I am :wink:

But people like me, who installed NC on a subdirectory, that is providing little adventures sometimes.

Well - maybe I would be bored without this :rofl:


Yes you are correct. Unless it’s absolutely necessary, and so far I’ve never run into a situation where it was necessary, I always prefer to use multiple VirtualHosts with different subdomains over subdirectories. That way all sites are nicely sparated, with their own config and DocumentRoot.

Seems like it. :wink: Not sure if Nextcloud is supposed to detect that and adjust the .htaccess file accordingly.

Honestly I am not sure, but as far as I remeber the archive I extracted for the initial setup, some years ago, created this subdirectory.

Of course I made the “mistake” to not move it prior the installation.

So in fact my NC has its own subdomain, where its installed in an subdirectory.
And yes, there no senseful reason for this :sob:

However I like to not move this cloud into its parental directory, as this technically just has to work this way as well.

But of course you are right

You don’t have to move it to its parent directory. You probably just have to adjust or add a DocumentRoot directive to your existing Virtualhost:

In your case the directive would look like this:

DocumentRoot /var/www/clients/client2/web14/web/nextcloud/

See also the example here: Installation on Linux — Nextcloud latest Administration Manual latest documentation

If you are hosting multiple sites in multiple subdirectories it gets a little more complicated, beacuse you would also have to separete those sites out into their own VirtualHosts. And of course, each of these Virtualhosts would need its own domain or subdomain, like cloud.yourdomain.com, wiki.yourdomain.com, www.yourdomain.com etc…

In my case thats not done by this - not for a long time perspective. The domains are managed by ISPC and if I made a resync, the default host template would be used again, what would overwrite this domains root directory again.

among some other possible problems I see that maybe might occur somewhen

No - if I move it i need to a migration in order to stay clean - also for the future.
But I have not too much time and the “effort-benefit-relation” here does not really convince me

I do not agree - you can very well host different softwares on one (sub)domain, installed within their individual subdirectories. I am having something like in place due to some complex reasons and it works very well.

But I must inmit that these softwares are all of a more simple nature - such as dokuwiki

Never said you can’t. But I should probably have been more clear in my wording…

My “EDIT” was referring to the question whether you would have to move Nextcloud (or any other sites) to the webserver’s root directory, if you were to switch from sub directories to subdomain(s) / VirtualHost(s).

The answer to that would be no, because you would simply have to change the DocumentRoot directive (if you only have one site).

If you have multiple sites, the change would get slightly more complicated, because you would also have to split the configurations for each site / sub folder into separate VirtualHosts, each with their own DocumentRoot and ServerName directives, in which case you would have multiple web roots, one for each site / subdomain.

In any case you wouldn’t have to move the existing (sub) folders around. However, if you are serving anything from the parent directory (/var/www/clients/client2/web14/web) you’d probably want to move that to a separate folder next to the others (e.g /var/www/clients/client2/web14/web/www).

Hope that cleras things up. :slight_smile:

Yes, but you are however able to divide configs within several ports :black_heart:

Yes I could, however I prefer to use a domain name with multiple sub domains.


That way I don’t have to remember IP addresses and port numbers. Also if I want to expose certain things to the internet, on my home internet connection with a dynamic IP, and / or if I want to use signed certificates from Let’s Encrypt, I need a domain name anyways. So why not just use it for everything then.

But you can of course handle it however you want, I was just trying to explain how I handle it.

I encountered the problem too, so I looked into the source code and ran the verification tools in debug mode. I did find a solution which I believe will work in future releases without change. I am running nextcloud in a subdirectory too, so the issue is really related to how the apache web server is “seeing” the subdirectory in the rewrite rules, whether they are in the .htaccess or in the virtual host configuration. I moved the code from the .htaccess file to the virtual host file, to allow me to visibly manage my various applications I have on my site. Here is the code that works. NOTE: the problem is calling the subdirectory as “/nextcloud”. As soon as I made the document root at the correct location for NextCloud to work, apache automatically removes the /nextcloud prefix. The solution to the problem is actually described in the apache documentation and on the NextCloud site under proxy configuration.

You will have to change the actual location of the files to match your site configuration, but this one does not require .htaccess to be installed anywhere.
Note that the key here is to explicitly specify the full path of the request that has to be rewritten, rather than assuming that /nextcloud will work:

<VirtualHost *:443>

ServerName cloud.mypublicdomain.com

Alias /nextcloud "/var/www_cloud/html/nextcloud/"

DocumentRoot "/var/www_cloud/html/nextcloud/"

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

	<IfModule mod_dav.c>
		Dav off
	<IfModule mod_rewrite.c>
		RewriteEngine on
		RewriteRule ^\.well-known/carddav https://%{SERVER_NAME}/nextcloud/remote.php/dav [R=301,L]
		RewriteRule ^\.well-known/caldav https://%{SERVER_NAME}/nextcloud/remote.php/dav [R=301,L]
		RewriteRule ^\.well-known/webfinger https://%{SERVER_NAME}/nextcloud/index.php/.well-known/webfinger [R=301,L]
		RewriteRule ^\.well-known/nodeinfo https://%{SERVER_NAME}/nextcloud/index.php/.well-known/nodeinfo [R=301,L]
		RewriteRule ^ocm-provider/?$ https://%{SERVER_NAME}/nextcloud/index.php [QSA,L]

# Block all robots on all subdirs
<Location "robots.txt">
	SetHandler None
Alias /robots.txt /var/www_cloud/html/robots.txt
# The following is a security recommendation in NextCloud doco
    <IfModule mod_headers.c>
            Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
SSLEngine on
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/cloud.mypublicdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cloud.mypublicdomain.com/privkey.pem

ErrorLog "logs/cloud_error_log"
    CustomLog "logs/cloud_access_log" combined


ln - s ocs-provider ocm-provider

solves it!

??? :upside_down_face:
Thanks, is there more information for us?

Well, I installed 27.1.3 this morning.

This was not a pleasant experience.

  1. The upgrade application was not happy that I did not have a .htaccess file and complained that I had a .htaccess.old file in the directory.
  2. Once I removed the .htaccess.old file, it proceeded to write a new .htaccess file with all the same old rewrite rules that do not work on an installation for “apache where the nextcloud is installed in a subdirectory.”
    Since I had gone through the debug of this problem before, this was immediately obvious when looking at the new .htaccess file created.

I solved the problem in a few minutes by deleting the new .htaccess file.

The better solution is not to cover up the “error” by adding symbolic links and opening up the server to having to always follow links, but to add the absolute reference for the server in the rewrite rules, as I have done. This can be done in either the .htaccess file or the server config file. But we know that the local .htaccess file has precedence over the server config, so if the upgrade process requires overwriting the .htaccess rule, I would recommend that we strongly encourage the developers to make this change in the upgrader/configurator, so that the .htaccess is more robust.