Skip to content

No option to select CalDAV/Apple #6

Closed

Description

@PrinzKenny1

Before submitting

  • I've searched existing issues and this isn't a duplicate.
  • This is a reproducible bug in Calnode — not a configuration/setup question or a feature request.

What's the bug?

Hi,
my colleague and I were just trying to connect our calendars and noticed that we had the CalDAV/Apple option once, then it didnt work for some reason and now the option is no longer showing up. Only Google and Microsoft show up as an option.

Steps to reproduce

  1. Go to home
  2. Click connect your calendar

See no option for caldav/apple.

Calnode version / commit

latest

How are you running Calnode?

Self-hosted — Docker

Logs, screenshots, or anything else

Image

Activity

  1. pullfrog commented on Aug 12, 2026

    @pullfrog
    Contributor
  2. shockalotti commented on Aug 18, 2026

    @shockalotti
    Contributor

    Thanks for the report! We've tried to reproduce this on a few fresh instances and CalDAV always shows up as an option, so this looks like it's specific to what's happening on your instance rather than a general bug in the CalDAV feature — we also just did an end-to-end test (connect → discovery → free/busy → booking write-back against a real CalDAV server) and it all worked correctly.

    A couple of things that would help us pin it down, if you're up for it:

    1. What does your Calendar settings page show right now? Does CalDAV appear anywhere — either as an existing connection (with a "Disconnect" button) near the top, or as a "Connect" option further down? A screenshot of the full page would help.
    2. Container startup logs, if you still have access to the instance:
      docker logs <your-container-name> 2>&1 | grep -i "calendar\|caldav"
      
      Looking for CalDAV calendar configured (fine) vs caldav: init failed (tells us exactly what broke).
    3. Which image tag is actually running:
      docker inspect <your-container-name> --format '{{.Config.Image}}'
      

    That said — if you'd rather not dig through logs, the fastest path back to a working state is probably to tear down the container/volume and redeploy fresh from the latest image. Given we can't reproduce this on new instances, whatever state your instance is in looks like a one-off rather than something everyone hitting the latest release would see. Happy to keep digging into root cause from the diagnostics above if you're able to grab them first, though — that'd help us catch a real bug if there is one under here.

  3. PrinzKenny1 commented on Aug 21, 2026

    @PrinzKenny1
    Author

    Hm, surprisingly it works now, even though we didn't change anything. Maybe a restart of the application fixed it, i'm not sure. But when i first started it and signed up as the initial user I also didn't get the owner role so maybe something hiccuped. Can be closed now.

  4. shockalotti commented on Aug 23, 2026

    @shockalotti
    Contributor

    AWESOME! Less work :) Ha ha. Closing now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions