Well known caldav error in docker container

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 32.0.1
  • Operating system and version (e.g., Ubuntu 24.04):
    • Docker/Linux
  • Web server and version (e.g, Apache 2.4.25):
    • Apache
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • nginx
  • PHP version (e.g, 8.3):
    • 8.3.27
  • Is this the first time you’ve seen this error? (Yes / No):
    • yes
  • When did this problem seem to first start?
    • after installation
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • docker compose
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • no

Summary of the issue you are facing:

In the Admin section says well know caldav (only caldav, not carddav) can’t be properly resolved.
I know there are many topics relatet to wellknown already but none provide a solution.
What I don’t understand is, that it is the docker container the comes already with apache included and the rewrite url is set, also the htaccess is fine and I can access the url.

Steps to replicate it (hint: details matter!):

  1. Install latest docker image

  2. overwrite.cli.url is set to the used domain

  3. htaccess rewrite base is /

  4. the htaccess says:
    RewriteRule ^.well-known/carddav /remote.php/dav/ [R=301,L]
    RewriteRule ^.well-known/caldav /remote.php/dav/ [R=301,L]

  5. https:///.well-known/caldav redirects to https:///remote.php/dav/ and shows: This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.

  6. I can add my Calendar via webdav into Outlook.

Log entries

logs seem fine, I couldn’t find any related error.

setup_warning_wellknown might be misleading as most or all checks are running on the server since few versions. The server might have different network connectivity like DNS, firewall rules etc. this might explain why your system works but the check fails. Try running curl https://cloud.mydomain.tld/.well-known/caldav from inside of the app container, and if the error is not obvious review log (eventually increase logs level) and repeat until you see the problem.

The answer I get is 301 moved to https://cloud.mydomain.tld/remote.php/dav/

Doing a curl for that gives:

<?xml version="1.0" encoding="utf-8"?>

<d:error xmlns:d=“DAV:” xmlns:s=" sabre/dav ">

<s:exception>Sabre\DAV\Exception\NotAuthenticated</s:exception>

<s:message>No public access to this resource., AppAPIAuth has not passed, This

request is not for a federated calendar, No ‘Authorization: Basic’ header found.

Either the client didn’t send one, or the server is misconfigured, No 'Authorizat

ion: Bearer’ header found. Either the client didn’t send one, or the server is mi

s-configured, No ‘Authorization: Basic’ header found. Either the client didn’t se

nd one, or the server is misconfigured</s:message>

</d:error>

when I access ../-well-known/caldav I see a redirect message (everywhere outside and inside of container)

#docker compose exec app curl -I https://cloud.mydomain.tld/.well-known/caldav

HTTP/2 307 
alt-svc: h3=":443"; ma=2592000
location: https://cloud.mydomain.tld/remote.php/dav/

and yes this is exactly the output above when I access /remote.php/dav/ using curl… a browser shows a login form

Sorry, but I don’t get how you post should help me.
This is the full output I get:

docker exec nextcloud_app curl -I https://cloud.mydomain.tld/.well-known/caldav
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
HTTP/2 301
server: nginx
date: Fri, 31 Oct 2025 06:59:31 GMT
content-type: text/html; charset=iso-8859-1
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
referrer-policy: no-referrer
location: http://cloud.mydomain.tld/remote.php/dav/
strict-transport-security: max-age=15768000; includeSubdomains; preload

I couldn’t find any direct error message, but when the container starts, I get this message, can this be related?

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.20.0.4. Set the 'ServerName' directive globally to suppress this message

is there a reason why you redirect to http:// ?

The container internally only has http as far as I understood.
The container runs behind a reverse proxy that only allows https.
Also in the config I have set ‘overwriteprotocol’ => ‘https’,

I don’t redirect anything on my own, the .htaccess is part of the container.