macOS "vergisst" CardDAV & CalDAV-Adresse

Debianer

Aktives Mitglied
Thread Starter
Dabei seit
21.06.2020
Beiträge
191
Reaktionspunkte
144
Ein Problem, was schon länger an macOS (14.1) nervt:

Ich betreibe mit Radicale einen CalDAV-/CardDAV-Server im LAN.
Domain: iobroker.fritz.box
Port: 5232, SSL aktiviert

Gebe ich die Daten in folgender Form unter Kontakte bzw. Kalender ein, funktioniert es!
D.h. Kalender und Kontakte werden synchronisiert.

Läßt man das Protokoll oder die Port-Angabe im Feld "Serveradresse" weg, funktioniert es nicht, auch wenn nachfolgend im Feld "Port" das richtige Nümmerchen steht und der Haken bei "SSL" gesetzt ist.
Das ist eindeutig ein Bug.
Das herauszufinden hat etwas gedauert. Wäre auch nicht tragisch, wenn die Sache damit gelöst wäre.

Vorher.png



Aber: Das funktioniert nur so lange, wie sich macOS nicht schlafen legt oder neu startet.
Danach sind die Eintragungen ohne meine Mitwirkung wie folgt überschrieben, was nicht funktioniert, da das Feld Port und der Haken SSL ignoriert werden.
Das Beispiel ist jetzt "Kontakte", das Verhalten in "Kalender" ist aber identisch.

Nacher.png



Weiss jemand wo mocOS diese Eintragungen abspeichert? Lässt sich das mit Boardmitteln lesbar machen?
Bzw. hat jemand eine Idee, die das Problem beheben kann?
iCloud ist keine Option, hier syncen auch andere OS.
 
iCloud ist keine Option, hier syncen auch andere OS.
Ich kenne Radicale nicht, mit NextCloud hingegen geht es bei mir problemlos, per https auf Port 443. Kannst Du vielleicht ein Portmapping auf 443 einrichten? Man kann solche Routen bspw. in der Fritzbox festlegen.

Die Implementierung von CalDav und CardDav auf dem Mac ist wackelig. Bspw. werden auch keine Serveradressen akzeptiert, die als subdomain ausgeführt sind (bspw. meinCalDavServer.meineadresse.de/…). Apple antwortet auf Supporteinträge mit dem Hinweis, dass es mit google ja schließlich einwandfrei funktioniere…
 
Ich kenne Radicale nicht, mit NextCloud hingegen geht es bei mir problemlos, per https auf Port 443. Kannst Du vielleicht ein Portmapping auf 443 einrichten? Man kann solche Routen bspw. in der Fritzbox festlegen.

Die Implementierung von CalDav und CardDav auf dem Mac ist wackelig. Bspw. werden auch keine Serveradressen akzeptiert, die als subdomain ausgeführt sind (bspw. meinCalDavServer.meineadresse.de/…). Apple antwortet auf Supporteinträge mit dem Hinweis, dass es mit google ja schließlich einwandfrei funktioniere…

In der FritzBox kann man so weit ich weiss nur einen externen Port zum Internet auf einen anderen Port intern umbiegen.
Innerhalb des LAN wäre mir die Möglichkeit nicht bekannt.

Radicale läuft als nicht priveligierter Prozess und macht als Nicht-root leider selbst keinen Port kleiner 1024 offen.
Aber auf Grund deines Hinweises mit dem Mapping habe ich das jetzt ganz einfach auf dem Server realisiert:

Bash:
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 5232

Funktioniert im Moment. So brauche ich die anderen Clients nicht umkonfigurieren.
Ich werde das so erst mal beobachten, ob es zur Problemlösung beiträgt.

Wie ja auch @Tommac187 schrieb, scheint die Implementierung von Apple nicht sonderlich stabil zu sein. Kann also beim nächsten Wakeup wieder sein, dass Kalender wieder nach demm Passwort fragt...
 
Wie ja auch @Tommac187 schrieb, scheint die Implementierung von Apple nicht sonderlich stabil zu sein.
Das kann man so pauschal nicht sagen. Ich habe das per Owncloud/Nextcloud schon viele Jahre zuverlässig laufen. Allerdings kann ich bestätigen, was @JeanLuc7 sagt: mit einer Subdomain wird es problematisch! Deshalb habe ich für meine Cloud eine eigene Domain.
 
okay, ich werde mich mal wieder in die Nesseln setzen, weil ich gegen so beliebte Software wie Nextcloud/Owncloud etc was sage, dennoch:

Das liegt sicher nicht an einer angeblich instabilen Implementierung von CardDAV/CalDAV seitens Apple (Apple hat sogar deine Referenzimplemtierung eines CardDAV/CalDAV-Servers veröffentlicht) sondern an der Konfiguration des hier betriebenen CardDAV/CalDAV-Servers. macOS kann auch problemlos mit CardDAV/CalDAV-Servern umgehen, die auf einer subdomain liegen, wenn man das ganze richtig auf dem Server konfiguriert.

Besonders wichtig da bei ist u.a. den ".well-known" Standard zu nutzen, anstatt der überall kursierendendieversen Pfad-Angaben. Dann klappt das auch noch nach dem Ruhezustand.

@JeanLuc7 @JackTirol

Dass CardDAV/CalDAV problemlos, und damit meine ich wirklich komplett problemlos, mit einer Subdomain läuft, habe ich in meinem Blog beschrieben. Der Artikel beschreibt als Software den Baikal-Server, welcher faktisch die Sabre/DAV-Referenzimplemtierung ist. Sabre/DAV wird auch von NextCloud/Owncloud etc verwendet, woran man dann erkennt, dass es eben an der config liegt, da ja Baikal definitv problemlos läuft. Mit Subdomains, nach Ruhe.

Insofern wäre mein Lösungsvorschlag: richte dir einen Baikal-Server ein

Hier der Link zum Artikel -> https://lisanet.de/baikal-kontake-und-kalender-auf-eigenem-webspace/
 
  • Gefällt mir
Reaktionen: Debianer und Wildbill
Also wie ich es auch drehe und wende, macOS und Radicale laufen nicht rund. Mein vermeintlicher Workaround oben ändert daran nichts. Mal klappt es temporär, mal geht gar nichts. Wobei ich nicht nachvollziehen kann, dass es immer wieder mal temporär funktioniert.

Das ist sehr schade, läuft mein Radicale-Setup gefühlt schon ewig und vollig geräuschlos und fast wartungsfrei mit Linux, Android, Thunderbird und DAVx5. Täglich automatisches Datenbank-Backup per Cron an NAS... Anbindung der Kalender an ioBroker... :cry:

Radicale hatte in Version 1 mal Parameter für ".well-known" in der Config. Das gibt es dort heute in Version 3 nicht mehr.
Allerdings finde ich auf Github auch Hinweise auf Probleme i.v.m. macOS, da geht es dann um unterschiedliche Anwendung von Befehlen im CalDAV Protokoll bei z.B. Thunderbird und macOS, und das auch noch in Abhängigkeit des verwendeten Ports. Ich bin jetzt nicht tiefer eingestiegen, das wird mir zu viel. Ich möchte aber weiter eine funktionierende, lokal gehostete Lösung für alle Clients haben. Offiziell wird macOS von Radicale nicht als "Supported Clients" gelistet - im Gegensatz zu Baikal.

Daher liebe @lisanet werde ich wohl deinem Rat folgen und mich an Baikal versuchen.
Ich glaube damals hatte ich mich für Radicale entschieden, weil es leichtgewichtiger und von der Config sehr knapp gehalten war.
 
Zurück
Oben Unten