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

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 :arrow_upper_right:. 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.

Did you try doing what the message suggests?

  • check .htaccess (for apache)
  • check nginx config (if applicable)

You didn’t post your topology or config (occ config:list system) so kind of hard to provide much other than general random ideas.

Some of the other log entries suggest you have debug logging on so change you log level. Check the Admin Manual[1] for hints.

The ocm-provider matter is a well traveled topic. Search the forum. :slight_smile:


1 Like

THX for taking care.
I don’t know what server is behind IONOS space
How to find out?

Since you’re paying them and they own the servers, I assume you can ask them. :slight_smile:

So They use Apache.
What’s next steps?

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.

Many THX

Is there something on GitHub
Where can I find the responsible developers to maybe conform the bug.

(Clients are getting nervous about this error) :upside_down_face: should give you an entry point. Even though closed, there is a new comment that the problem persists for at least one user in 28.0.1
gives probably the easiest way to temporarily get rid of the warning (even though I agree to the comments stating that the problem should be solved by the NC team):

root@machine:/var/www/html/nextcloud# ln -s ocs-provider ocm-provider

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.

root@machine:/var/www/html/nextcloud# ln -s ocs-provider ocm-provider

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. 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

[1] [Bug]: Your web server is not properly set up to resolve "/nextcloud/ocm-provider/" · Issue #40803 · nextcloud/server · GitHub

1 Like

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:

  1. 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.
  2. 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.

In my Fedora 39 the default httpd.conf sets

AllowOverride none

basically everywhere:

DocumentRoot "/var/www/html"
<Directory />
    AllowOverride none
    Require all denied
<Directory "/var/www">
    AllowOverride None
    Require all granted
<Directory "/var/www/html">
    AllowOverride None
<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options None
    Require all granted

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
DocumentRoot /var/www/html/nextcloud
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
#   configuration_server/reverse_proxy_configuration.html#apache2
#   < Syntax ist für *.conf-Dateien richtig
#   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.
Well, I go with the solution to enable .htaccess, copy-paste of the solution by BenS89 at the link above.
Removed the rewrite-Rules from the VirtualHost to be free of redundance.
Seems most reasonable, works and still gives A+ rating at

Maybe someone can anyhow post a solution for ocm-provider inside an ssl.conf as opposed to .htaccess - I would be curious.

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! :face_with_monocle: