Hi, I have my Nextcloud installation on IONOS Webspace!
After update to 28.0.1 I now have this error.
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 . On Nginx those are typically the lines starting with “location ~” that need an update.
57 errors in the logs since 22. Dezember 2023
some are:
No calendar events found for status check
29.12.2023, 22:01:23
Debug cron
Finished OCA\Files\BackgroundJob\ScanFiles job with ID 3 in 0 seconds
29.12.2023, 22:00:03
Debug cron
Run OCA\Files\BackgroundJob\ScanFiles job with ID 3
Debug no app in context
Running check OCA\Settings\SetupChecks\TransactionIsolation
As I have no access to the server and IONOS support is not amused to have a Nextcloud on their space, I want to ask here if there is some solution to get this fixed.
I have access to the root DIR.
Maybe something is also possible with OCC commands.
Many THX for ideas to solve this on IONOS Hosting.
Maybe you want to check this:
[Problem with ocm-provider Verzeichnis /var/www/html/nextcloud/ocm-provider/ existiert nicht mehr in NC 27.1.2]
My conclusion from that is, that this is a false warning message, the checking tool does seem to be outdated. So I decided for me to ignore it for now and wait for an update by the Nextcloud team.
I have the same problem in NC 28.0.1 and had it until some minutes ago in NC 27.1.2.
According to the link it should disappear with NC 27.1.3 which I never installed however.
In my instance the DocumentRoot is /var/www/html/nextcloud/ and the folder /var/www/html/nextcloud/ocs-provider (still) exists. Whether this then works or only satisfies the check - no idea on my side.
Please don’t do this. ocm-provider is not supposed to exist as an actual file or folder these days. It’s handled internally by Nextcloud Server (via index.php specifically)[1].
There was some confusion because there was breakage in a release version for people with Nextcloud hosted in a sub-folder (e.g. https://mydomain.com/nextcloud/ rather than the root). There was a manual workaround, but it’s no longer necessary: that was fixed in all current patch levels.
The subfolder breakage created extra confusion because it was occurring at the same time that other people were seeing the same warning come up but for different reasons.
Those threads/issues are full of lots of workarounds and conflicting bits of advice because people had various reasons for this error arising.
If you’re using a current patch level (of any of NC26/NC27/NC28) there are no known bugs with this check.
However there are various situations where you may encounter it broken in your environment:
if your environment ignores the distributed .htaccess file that gets created at install time
if you’ve manually modified the .htaccess file so it no longer matches the one distributed in the patch level of NC you’ve deployed
if your environment is NGINX based (you need to port your own config - just as you do anytime the NGINX config needs to be updated - see the latest Admin Manual for an up-to-date example)
various circumstances that are generally variations on the above
However there are various situations where you may encounter it broken in your environment:
if your environment ignores the distributed .htaccess file that gets created at install time
That’s my situation I guess.
In short:
I would like to know:
Can I savely allow usage of /var/www/html/nextcloud/.htaccess (exactly and only that special file) inside a VirtualHosts definition in one of the *.conf files and if yes, how?
Then I would kick out the rewrite rules that work and that I transferred there form the .htaccess default file).
That is what I would prefer, assuming that it covers everything needed, not just what I understood up to now.
OR
Should I transfer just what I need to VirtualHost ssl.conf
which is recommended in many places of the latest NC admin doku and keep ignoring .htaccess?
From the latest NC Admin Doku I am more than confused on what to do where: VirtualHost definition sections in any *.conf vs. usage of *.htaccess, but that’s another topic.
So in general me as a beginner would suppose this is OK and safe.
My target is that no user can fool around with potentially bad .htaccess content.
That’s why I left it like that and put the other rewrite-rules to the ssl.conf
<VirtualHost _default_:443>
# General setup for the virtual host, inherited from global configuration
ServerName xx.dyn.cc
ServerAlias www.xx.dyn.cc
DocumentRoot /var/www/html/nextcloud
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
</IfModule>
# https://docs.nextcloud.com/server/27/admin_manual/\
# configuration_server/reverse_proxy_configuration.html#apache2
# < Syntax ist für *.conf-Dateien richtig
# https://docs.nextcloud.com/server/27/admin_manual/issues/\
# general_troubleshooting.html#service-discovery
RewriteEngine on
RewriteRule ^/\.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav /remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/webfinger /index.php/.well-known/webfinger [R=301,L]
RewriteRule ^/\.well-known/nodeinfo /index.php/.well-known/nodeinfo [R=301,L]
RewriteRule ^/ocm-provider/?$ /index.php [QSA,L]
The last line does not work according to the NC checks.
It is taken from the default /var/www/html/nextcloud/.htaccess
but Syntax is modified like for the other RewriteRules to have the ^/ocm- in the beginningn, not ^ocm, like in .htaccess.
Das ocm-providerGeraffel lässt sich ganz einfach abstellen, ohne irgendwelche Dateien verändern zu müssen. Grundsätzlich darf davon ausgegangen werden, dass die Konfigurationen von Apache oder Nginx funktioniert haben und auch noch funktionieren.
Was sich verändert hat - es gibt kein Verzeichnis ocm-provider im NextcloudVerzeichnis mehr. Stattdessen gibt es ein ocs-providerVerzeichnis unter /nextcloud, Bitte im Verzeichnis /nextcloud zusätzlich ein Verzeichnis ocm-provider anlegen und dem User und der Gruppe www-data zuordnen. Anschließend den Apache oder Nginx neustarten, und das lästige ocm-providerGeraffel ist weg.
Wo kein ocm-providerVerzeichnis, benötigt man auch keine RewriteRule für den “Scheiß”. Diese also bitte einfach per # auskommentieren. Man weiß schließlich nicht, ob die Entwickler irgendwann mal wieder ein ocm-providerVerzeichnis und eine diesbezügliche RewriteRule für erforderlich halten.
Warum die diesbezügliche PrüfRoutine in puncto ocm-provider nicht schon längst korrigiert wurde, entzieht sich meiner Kenntnis. Vermutlich haben die Entwickler so ihren Spaß, wenn die Anwender immer mal wieder wie der Ochse vorm Berg stehen, sich die Finger wund tippen und wertvolle Zeit tot schlagen.
Da passt es auch ins Bild, wenn man nach einem Update das Verzeichnis ocm-provider im Verzeichnis /nextcloud erneut anlegen muss, sonst taucht die beschissene Meldung erneut auf.
Ich nenne das “schlampige Beaufsichtigung der hinterlegten Prüfroutine”!
Scheint die Verantwortlichen nicht zu interessieren.
Professionell ist das jedenfalls nicht!
. On Nginx those are typically the lines starting with “location ~” that need an update.
