DAV resolving issues on web interface

Hi all,

I’m having DAV resolving issues within the Files app on the web interface. Once I manually navigate my browser to https://cloud.sjengkraftkompenei.nl/remote.php/dav/files/LucS (a valid user), I get the message “This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.” from which I can hopefully conclude that web server configuration is correct (please tell me otherwise if I’m wrong). Also the iOS app works fine, there I can navigate the folders like I’m used to.

However, within the Files app on the web interface, it doesn’t matter what folder I click on, I get the error “Folder not found” and I can click “Retry” until my finger falls off. Clearing the browser console and clicking retry once again gives the following errors:

In the administration settings, the Security and Setup warnings gives me
“Your web server is not properly set up to resolve .well-known URLs, failed on: /.well-known/caldav For more details see the documentation”. I have been editing the .htaccess file according to the documentation, it should be correct according to my judgement:

htaccess file
  <IfModule mod_setenvif.c>
    <IfModule mod_fcgid.c>
       SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
       RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
    </IfModule>
    <IfModule mod_proxy_fcgi.c>
       SetEnvIfNoCase Authorization "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>
    <IfModule mod_lsapi.c>
      SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
      RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
    </IfModule>
  </IfModule>

  <IfModule mod_env.c>
    # Add security and privacy related headers

    # Avoid doubled headers by unsetting headers in "onsuccess" table,
    # then add headers to "always" table: https://github.com/nextcloud/server/pull/19002
    Header onsuccess unset Referrer-Policy
    Header always set Referrer-Policy "no-referrer"

    Header onsuccess unset X-Content-Type-Options
    Header always set X-Content-Type-Options "nosniff"

    Header onsuccess unset X-Frame-Options
    Header always set X-Frame-Options "SAMEORIGIN"

    Header onsuccess unset X-Permitted-Cross-Domain-Policies
    Header always set X-Permitted-Cross-Domain-Policies "none"

    Header onsuccess unset X-Robots-Tag
    Header always set X-Robots-Tag "noindex, nofollow"

    Header onsuccess unset X-XSS-Protection
    Header always set X-XSS-Protection "1; mode=block"

    SetEnv modHeadersAvailable true
  </IfModule>

  # Add cache control for static resources
  <FilesMatch "\.(css|js|mjs|svg|gif|png|jpg|webp|ico|wasm|tflite)$">
    <If "%{QUERY_STRING} =~ /(^|&)v=/">
      Header set Cache-Control "max-age=15778463, immutable"
    </If>
    <Else>
      Header set Cache-Control "max-age=15778463"
    </Else>
  </FilesMatch>

  # Let browsers cache OTF and WOFF files for a week
  <FilesMatch "\.(otf|woff2?)$">
    Header set Cache-Control "max-age=604800"
  </FilesMatch>
</IfModule>

<IfModule mod_php.c>
  php_value mbstring.func_overload 0
  php_value default_charset 'UTF-8'
  php_value output_buffering 0
  <IfModule mod_env.c>
    SetEnv htaccessWorking true
  </IfModule>
</IfModule>

<IfModule mod_mime.c>
  AddType image/svg+xml svg svgz
  AddType application/wasm wasm
  AddEncoding gzip svgz
  # Serve ESM javascript files (.mjs) with correct mime type
  AddType text/javascript js mjs
</IfModule>

<IfModule mod_dir.c>
  DirectoryIndex index.php index.html
</IfModule>

<IfModule pagespeed_module>
  ModPagespeed Off
</IfModule>

<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]
</IfModule>

# Clients like xDavv5 on Android, or Cyberduck, use chunked requests.
# When FastCGI or FPM is used with apache, requests arrive to Nextcloud without any content.
# This leads to the creation of empty files.
# The following directive will force the problematic requests to be buffered before being forwarded to Nextcloud.
# This way, the "Transfer-Encoding" header is removed, the "Content-Length" header is set, and the request content is proxied to Nextcloud.
# Here are more information about the issue:
#  - https://docs.cyberduck.io/mountainduck/issues/fastcgi/
#  - https://docs.nextcloud.com/server/latest/admin_manual/issues/general_troubleshooting.html#troubleshooting-webdav
<IfModule mod_setenvif.c>
  SetEnvIf Transfer-Encoding "chunked" proxy-sendcl=1
</IfModule>

# Apache disabled the sending of the server-side content-length header
# in their 2.4.59 patch updated which breaks some use-cases in Nextcloud.
# Setting ap_trust_cgilike_cl allows to bring back the usual behaviour.
# See https://bz.apache.org/bugzilla/show_bug.cgi?id=68973
<IfModule mod_env.c>
  SetEnv ap_trust_cgilike_cl
</IfModule>

AddDefaultCharset utf-8
Options -Indexes
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 /index.php/error/403
ErrorDocument 404 /index.php/error/404```

Could you please help me in troubleshooting as to what is going wrong here? Please let me know if more info is needed. Thanks so much in advance!

Config
  • Nextcloud Server version (e.g., 29.x.x):
    • 30.0.4
  • Operating system and version (e.g., Ubuntu 24.04):
    • Linux 4.18.0-513.18.1.el8_9.x86_64 x86_64
  • Web server and version (e.g, Apache 2.4.25):
    • Apache 2.4.62
  • PHP version (e.g, 8.3):
    • PHP 8.3 (ea-php83)
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • A couple of weeks ago, seemingly after an update
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AIO

Glad you used the support template.

You missed/removed the part where it comes to the log files of nextcloud and your webserver.

Anything suspicious in there?

btw. opened your domain and from here it is really, really slow until the login form is getting loaded.

Once I manually navigate my browser to https://cloud.sjengkraftkompenei.nl/remote.php/dav/files/LucS (a valid user), I get the message “This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.” from which I can hopefully conclude that web server configuration is correct (please tell me otherwise if I’m wrong).

The test is running against https://cloud.sjengkraftkompenei.nl/.well-known/caldav. Specifically it’s running a PROPFIND (not a GET like your browser will send by default).

In the administration settings, the Security and Setup warnings gives me
“Your web server is not properly set up to resolve .well-known URLs, failed on: /.well-known/caldav For more details see the documentation”. I have been editing the .htaccess file according to the documentation, it should be correct according to my judgement:

Modifying the shipped .htaccess only applies if you’re running Nextcloud via a subfolder. That doesn’t look to be the case for you, so you should use an unmodified .htaccess.

From the looks of it, your reverse proxy (Cloudflare it looks like) is returning a 404 for PROPFIND HTTP requests to the above URL:

> PROPFIND /.well-known/carddav HTTP/2
> Host: cloud.sjengkraftkompenei.nl
> user-agent: curl/7.88.1
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 404 

So the test is failing for good reason. This is a configuration matter presumably with your CF services.

Hi @jtr , first of all thanks for your reply and in depth suggestions.

To be sure that I have the right .htaccess file, I downloaded the server v30.0.4 source code from Github and replaced the existing .htaccess file with the one from the source code. I trust that the .htaccess then shouldn’t be the culprit anymore.

As for Cloudflare, I paused Cloudflare’s functionality on the entire domain to make sure Cloudflare isn’t a part of all the connectivity anymore. However, the issue sadly still persists. On the web interface, the result is the exact same as the screenshot posted in the original post, and performing a PROPFIND curl towards cloud.sjengkraftkompenei.nl/.well-known/caldav still returns a 404.

Maybe worth noting that, when I leave the browser tab open for a while on the Files app, the console also returns 404 errors on the PUT request for the heartbeat, and deleting notifications also doesn’t work because of a 404 error on the DELETE request towards the API. See the screenshot below.

Seeing how the .htaccess and Cloudflare are now out of the equation and with the extra info, do you possibly have more or new ideas as to what the issue could be? Again, thanks a lot already just for thinking along.

Hi @rakekniven ,

Thanks for your reply. The Nextcloud logs unfortunately don’t report anything within the testing timeframes. The Apache logfiles are sadly inaccessible, as I’m using a webhosting service and have installed Nextcloud on my webspace using Installatron. A possible vital part which I stupidly forgot to mention, so sorry about that. The webhoster does allow me to SSH, but only inside my own webspace, so I don’t have read permissions in the server’s Apache logs.

Since you are using pretty URLs, make sure htaccess.RewriteBase is set to / (and maybe overwrite.cli.url) and re-run occ maintenance:update:htaccess manually (it’ll make some adjustments to your clean .htaccess). You’ll need to do that anyhow to update the downloaded .htaccess for your environment. Docs link: Pretty URLS.

Though I don’t see how that would only impact PROPFIND requests still on your web server.

Can you check your Apache error log for clues?

Are you using anything like mod_security? Do you have any thing in your global Apache config that is non-default (such as a Limit* referencing HTTP methods like PROPFIND, GET, HEAD, etc.

I added the 'htaccess.Rewritebase' => '/' and 'overwrite.cli.url' => 'https://cloud.sjengkraftkompenei.nl' entries to the config.php file and updated the .htaccess file through the occ maintenance:update:htaccess command.

Unfortunately the issue still persists, however I do have pretty links now where I didn’t have them yet before. :sweat_smile:

Also I unfortunately can’t check Apache’s error logs since I’ve installed Nextcloud on a shared webhosting platform using Installatron. The webhoster sadly hasn’t granted me permissions to view the server’s Apache error logs. Going through the filesystem I do see some modsec.conf files, so it’s indeed highly likely that mod_security is active.

I do see though that in the /etc/apache2/conf.d/modsec folder there is a file modsec.user.conf, and in there a rule setvar:tx.crs_exclusions_nextcloud=1, exists. But I’m not experienced enough with Apache to say for sure whether this means that the Nextcloud application should be excluded from Apache’s mod_security configurations…

That’s likely the cause, but to know for sure you’ll need to see the logs. That’s why we ask if one is using mod_security in the support template. :wink: It’s noted to create problems.

Even if it’s still not mod_security, the Apache error log is what you need to figure out what’s going on. Something somewhere in the end-to-end path there is blocking PROPFIND HTTP methods, and you’ve eliminated CF.