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.
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.
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.
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.
Yes, thats indeed nice for people like you - I totally begrudge you this privilege
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
But people like me, who installed NC on a subdirectory, that is providing little adventures sometimes.
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. Not sure if Nextcloud is supposed to detect that and adjust the .htaccess file accordingly.
EDIT:
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).
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>
<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]
</IfModule>
</Directory>
# Block all robots on all subdirs
<Location "robots.txt">
SetHandler None
</Location>
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"
</IfModule>
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
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.
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.
(why whjy why) 
