Well known caldav error in docker container

Thor · October 26, 2025, 6:04pm

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

Install latest docker image
overwrite.cli.url is set to the used domain
htaccess rewrite base is /
the htaccess says:
RewriteRule ^.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^.well-known/caldav /remote.php/dav/ [R=301,L]
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.
I can add my Calendar via webdav into Outlook.

Log entries

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

wwe · October 27, 2025, 1:43pm

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.

Thor · October 30, 2025, 7:18pm

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>

wwe · October 30, 2025, 9:02pm

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

Thor · October 31, 2025, 7:06am

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

wwe · October 31, 2025, 10:10am

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

Thor · October 31, 2025, 11:40am

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.

wwe · October 31, 2025, 8:45pm

looks like your reverseproxy is doing the redirect..

Thor · October 31, 2025, 10:28pm

again, I don’t know how this post is supposed to help.
I set up the container based on the documentation, taking into account the config settings for the reverse proxy.

Those are the settings of the reverse proxy. Same settings are mentioned in tutorials and the nextcloud-aio github page.

#

The redirect works for anyone outside, based on your explanation, the redirect is not working on the server side.
Still I don’t understand why the error message only shows up for caldav not for carddav.

So, no the reverse proxy is not redirecting /well-known. I can show you the complete reverse-proxy conf file, if that helps.

jtr · November 1, 2025, 2:44am

Please post your actual Nextcloud config (as noted in the support template and do so by using occ config:list system preferably since most of the Docker images used multiple config files + environment variable injection so just looking at config.php isn’t enough) as well as your Docker Compose.

Based on a few clues in the thread so far, don’t believe you’re actually using the AIO image/stack. Possiblly the community micro-services image, but there are other possibilities.

Also, can you clarify specifically what RP you’re using? Standard nginx does not have that UI. It appears to be one of the third party ones, possibly Synology’s.

Thor · November 1, 2025, 7:43am

Yes, it is not the AIO image, it is the community one. I just went through several resources to verify if a special setup for the RP is needed and yes it is the Synology RP.

Docker Compose:

services:
  mariadb:
    image: mariadb:11.5.2
    container_name: nextcloud_mariadb
    restart: unless-stopped
    networks:
      - nextcloud
    volumes:
      - ./mariadb:/var/lib/mysql
    environment:
      - MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1

  redis:
    image: redis:alpine
    container_name: nextcloud_redis
    restart: unless-stopped
    command: redis-server --requirepass Th1s-1s-a-pa22phra2e-for-red12
    networks:
      - nextcloud
  
  nextcloud:
    image: nextcloud:32.0.1
    container_name: nextcloud_app
    depends_on:
      mariadb:
        condition: service_started
      redis:
        condition: service_started
    restart: unless-stopped
    ports:
      - 81:80
    links:
      - mariadb
      - redis
    networks:
      - nextcloud
    volumes: 
      - ./apps:/var/www/html/custom_apps
      - ./config:/var/www/html/config
      - ./data:/var/www/html/data 
      - ./nextcloud:/var/www/html
      - ./themes:/var/www/html/themes/custom
      - /volume1/photo/Test:/test
    environment:
      - PHP_MEMORY_LIMIT=4048M
      - PHP_UPLOAD_LIMIT=4048M
      - TRUSTED_PROXIES=192.168.13.201
      - OVERWRITEHOST=todo.viking-studios.net
      - OVERWRITEPROTOCOL=https
      - OVERWRITECLIURL=https://todo.viking-studios.net
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - REDIS_HOST_PASSWORD=Th1s-1s-a-pa22phra2e-for-red12

networks:
  nextcloud:
    name: nextcloud
    driver: bridge

And the config

{
“system”:
{
“htaccess.RewriteBase”: “/”,
“apps_paths”: [
  {“path”: “/var/www/html/apps”,
  “url”: “/apps”,“writable”: false},
  {“path”: “/var/www/html/custom_apps”,
  “url”: “/custom_apps”,“writable”: true}],
“overwritehost”: “REMOVED SENSITIVE VALUE”,
“overwriteprotocol”: “https”,
“overwrite.cli.url”: “REMOVED SENSITIVE VALUE”,
“trusted_proxies”: “REMOVED SENSITIVE VALUE”,
“upgrade.disable-web”: true,
“instanceid”: “REMOVED SENSITIVE VALUE”,
“passwordsalt”: “REMOVED SENSITIVE VALUE”,
“secret”: “REMOVED SENSITIVE VALUE”,
“trusted_domains”: [“REMOVED SENSITIVE VALUE”],
“datadirectory”: “REMOVED SENSITIVE VALUE”,
“dbtype”: “mysql”,
“version”: “32.0.1.2”,
“dbname”: “REMOVED SENSITIVE VALUE”,
“dbhost”: “REMOVED SENSITIVE VALUE”,
“dbtableprefix”: “oc_”,
“memcache.local”: “\OC\Memcache\APCu”,
“memcache.distributed”: “\OC\Memcache\Redis”,
“memcache.locking”: “\OC\Memcache\Redis”,
“redis”: 
  {“host”: “REMOVED SENSITIVE VALUE”,
  “password”: “REMOVED SENSITIVE VALUE”,
  “port”: 6379},
“mysql.utf8mb4”: true,
“dbuser”: “REMOVED SENSITIVE VALUE”,
“dbpassword”: “REMOVED SENSITIVE VALUE”,
“installed”: true,
“maintenance”: false}}

Thor · November 2, 2025, 12:21am

I could fix it.
The solution is from here

Based on the fact that the issue is a check, that is running on the server, the issue shouldn’t be related to the reverse proxy (correct me, if my assumption is wrong).
The NC server is running on apache that is part of the container.
As initially stated, there are a ton of threads, posts and tutorials on many sides that are somehow related to well-known issues stating more or less the same solution and the .htaccess within the container matched those solutions.
I fund that thread more or less by accident, looking for something different.

system · November 10, 2025, 12:22am

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.