Wenn der Kalender lügt: Eine Fehlersuche zwischen Thunderbird, Nextcloud und einem falschen Passwort

Problem

Ein Kalender, der über CalDAV mit einer eigenen Nextcloud-Instanz verbunden ist, deaktiviert sich unter Ubuntu immer wieder von selbst. Auf anderen Geräten sind Termine und Aufgaben längst aktuell – nur der Linux-Rechner hinkt hinterher. Die Fehlerkonsole zeigt eine Zeile wie diese (Server-Adresse hier anonymisiert):

[calCachedCalendar] replay action failed: null, uri=https://beispiel.tld/remote.php/dav/calendars/nutzer/kalender/, result=2147500037

Auf den ersten Blick sieht das nach einem Softwarefehler aus. Der Fehlercode selbst ist aber ein Generalist – er bedeutet nur "beim Zurückschreiben von Änderungen ist etwas schiefgelaufen", ohne zu sagen, warum. Genau das macht solche Meldungen tückisch: Sie laden dazu ein, vorschnell zu handeln – neu installieren, Cache löschen, App löschen und hoffen, dass es beim zweiten Versuch klappt. Das sind die häufigsten Ratschläge im Netz und im Bekanntenkreis, oft ganz ohne Logik oder echte Fehlersuche dahinter.

Lösung

Der bessere Weg ist, Kandidaten systematisch auszuschließen, bevor man etwas verändert:

Sandboxing der Anwendung? Ein Blick auf die Berechtigungen zeigte: kein Zugriff auf einen Passwort-Manager-Dienst überhaupt vorgesehen, Netzwerk-Zugriffe sauber verbunden. Diese Spur führte ins Leere.
Mailsynchronisation als Kontrollgruppe: Die lief einwandfrei, ohne jede Störung. Das schloss ein generelles Netzwerk- oder Zertifikatsproblem der Anwendung aus – der Fehler saß spezifisch im Kalender-Protokoll.

Erst der Blick auf die eigentliche Netzwerkanfrage brachte Klarheit: Die Anfrage an die Kalender-Adresse kam mit HTTP 401 – Unauthorized zurück. Kein Bug, keine Sandbox. Der Server lehnte schlicht die verwendeten Zugangsdaten ab.

Die eigentliche Ursache: Nachdem ich die Anmeldung um einen 2. Faktor erweitert hatte – wie man es von Banken und anderen Zugängen kennt – reicht das normale Konto-Passwort für den Kalender-Zugriff nicht mehr. Nötig ist ein eigenes App-Passwort. Das Mailprogramm hatte jedoch noch einen alten, davon unabhängigen Zugang gespeichert und griff bei jedem automatischen Sync-Versuch weiter darauf zurück – unabhängig davon, was beim Einrichten manuell eingegeben wurde. Kalender entfernen, mit dem korrekten App-Passwort neu einbinden, Problem gelöst.

Ergebnis

Der Sync läuft seither zuverlässig. Um sicherzugehen, dass beim Löschen und Neu-Einrichten nichts verloren ging, wurde der Kalender vorher und nachher exportiert und automatisiert verglichen: 336 Einträge vorher, 372 nachher. Nichts davon war tatsächlich verloren gewesen – die zusätzlichen Einträge lagen auf anderen Geräten längst sauber vor und wurden beim Neu-Einbinden einfach nachgezogen. Ein handfester Vorteil zentral gespeicherter Kalenderdaten – fällt ein Gerät aus, bleibt der Bestand woanders intakt. Die drei übrigen Abweichungen im Vergleich ließen sich eindeutig auf reale Ereignisse zurückführen (eine Absage, eine Verschiebung, ein Duplikat) – kein Datenverlust durch den Eingriff selbst.

Die eigentliche Erkenntnis für den Alltag: "Einfach neu installieren" oder "Cache löschen" ist kein Fehlerbehebungsplan, sondern Raten mit Extraschritten. Ein systematisches Ausschlussverfahren – erst die naheliegenden, dann die unwahrscheinlicheren Ursachen – findet die Wahrheit zuverlässiger. Das braucht entweder eigene Erfahrung mit solchen Systemen – oder jemanden, der sie hat. Und ein Vorher-Nachher-Vergleich der eigenen Daten ist der einzige echte Beweis dafür, dass ein Fix wirklich funktioniert hat, nicht nur "sieht jetzt besser aus".

Nebenbei: Das Mailprogramm hinter dieser Geschichte ist Thunderbird – kostenlos, quelloffen und in der täglichen Praxis genauso leistungsfähig wie Outlook oder Apple Mail. Der Kalender-Server dahinter ist eine selbst in Deutschland gehostete Nextcloud-Instanz – ebenfalls quelloffen: dieselbe Zentralisierung, die auch Google oder Apple bieten, nur eben in eigener Hand, DSGVO-konform und ohne Daten bei einem Konzern.