CalDAV-Login-Problem mit MacOS 10.11 und NC 13

Beim Versuch einen CalDAVAccount in der Kalender-App von Mac OS 10.11.6 hinzuzufügen bekomme ich die Fehlermeldung “Accountname/Passwort konnte nicht überprüft werden.”

Ich habe als Accounttyp “Manuell” gewählt, Benutzername und Passwort eingegeben und als Serveradresse den kompletten Link eingefügt, der in der Kalender-App von NextCloud bei “Einstellungen & Import” als “iOS-/OS-X-CalDAV-Adresse” angezeigt wird.

Auf dem Host läuft NextCloud 13 auf Ubuntu 16.04.3 LTS (Kernel 4.4.0-96-generic). Ich habe ein fertiges VirtualBox-Image von www.techandme.se installiert. Der Host für die VirtualBox ist ein Mac mit System 10.13.3, der eine öffentliche IP hat. Die Verbindung zwischen VirtualBox und Mac wird durch einen NAT-Netzwerkadaper hergestellt, der den Port 8080 vom Mac auf den Port 443 von Ubuntu umleitet.

Der Zugriff mit dem Browser per https funktioniert, auch mit der Nextcloud-App kann ich mich via WebDAV problemlos mit dem Server verbinden.

Während des Troubleshooting habe ich mich erfolgreich mit verschiedenen anderen NextCloud- und OwnCloud(v10)-Servern verbunden. CalDAV als solches scheint also von meinem Rechner aus zu funktionieren.

Hat jemand einen Tipp, was ich als nächstes tun könnte?

Edit: Von einem anderen Rechner mit MacOS 10.9 funktioniert die Verbindung, habe ich gerade festgestellt. Was könnte das sein?

1 Like

Habe das selbe Problem, ich wende mich ma an den Suport und melde mich dann hier Wieder wenn ich eine Antwort habe.

Super - mal sehen, was die sagen.

Gibst du dann beim caldav-server hinzufügen als Port 8080 ein? Bin mir nicht sicher, ob Mac OS mit nicht-Standard Ports umgehen kann…

Ja:
https://exmple.com:8080/nextcloud/remote.php/dav/calendars/bigwaf/

Bei WebDAV per NextCloud-App funktioniert es, beim Adressbuch per CardDAV hat es bis gestern funktioniert. Bei CalDAV noch gar nicht.

Ich meinte eigentlich nur den in Mac OS integrierten caldav/carddav client. Hatte mich nicht deutlich ausgdrückt. Sorry. Wenn carddav funktioniert hat, sollte es ja aber eigentlich gehen.

Als nächstes würde ich nachschauen, ob die Tabelle oc_bruteforce_attempts viele Einträge hat (der prefix “oc_” lautet bei deiner Installation vielleicht anders). Hier habe ich schon einmal beschrieben wie das geht:

Wenn das nicht hilft: hast du es denn schon einmal mit Service-discovery versucht (ist auf englisch, ich kann bei Bedarf gerne übersetzen)?
EDIT: als account müsstest du dann USERNAME@EXAMPLE.COM:8080 angeben (also mit Portnummer):

Wenn das immer noch nicht hilft: gibt denn das Webserver-Log irgendwas her? Was sagt die Konsole von Mac OS, wenn du versuchst einen account hinzuzufügen?

Vielen Dank für die ausführlichen Tipps!

  • bruteforce_attempts hatte 75 Einträge. Ich habe sie gelöscht, und bei meinen heutigen Loginversuchen sind keine neuen dazugekommen.

  • Ich habe die Service Discovery Einträge in der .htaccess gemacht.

  • In Kalender habe ich diesmal beim Anlegen des neuen Accounts “Automatisch” gewählt und als Benutzername USERNAME@EXAMPLE.COM:8080 eingegeben (Natürlich habe ich statt USERNAME meinen Benutzernamen und statt EXAMPLE.COM die URL meines Servers eingegeben).

  • Bingo! Der Login war erfolgreich, der Account wurde angelegt!!

  • Dann kam die Meldung:
    "Der Server meldet einen Fehler.
    https://EXAMPLE.COM:8080/remote.php/dav/principals/users/USERNAME/“ ist keine gültige URL, die diese Anfrage unterstützt."
    Ich habe auf “Erneut versuchen” geklickt.

  • Dann habe ich das Kalender-Fenster gewechselt. Dort kam die Meldung noch mal, und ich habe wieder “erneut versuchen” geklickt

  • die geteilten Kalender erschienen links in der Kalenderleiste und wurden geladen

  • rechts vom Servernamen wird seitdem ein kleines Warndreieck mit Ausrufezeichen angezeigt. Ich habe daraufgeklickt und es kam die Meldung:
    "Es konnte keine Verbindung zum Account EXAMPLE.COM:8080 hergestellt werden."
    Ich wurde zur Eingabe meines Passworts aufgefordert. Habe ich gemacht.

  • nach dem Beenden und neu Starten des Kalenderprogramms kommt die erste Meldung wieder und das Warnzeichen steht auch neben dem Servernamen. Nach weiterem Beenden und neu Starten kommt die Meldung nicht mehr, aber das Warndreieck bleibt. Klick auf das Warndreieck führt jetzt nicht mehr zur Passwortabfrage.

Es wurde nur ein Teil der Termine in allen drei geteilten Kalendern übertragen und neu eingetragene Testtermine werden nicht synchronisiert.

Erstmal super, aber noch nicht ganz. Es hat eine Synchonisation begonnen, die ist aber nicht fertig geworden und seitdem nicht mehr zustande gekommen.

Hast du noch weitere Ideen dazu?

Das habe ich aus der Konsole gefischt:

13.3.18 22:19:11,055 CalendarAgent[377]: [com.apple.calendar.store.log.caldav.queue] [Account refresh failed with error: Error Domain=CoreDAVHTTPStatusErrorDomain Code=401 “(null)” UserInfo={AccountName:8080=EXAMPLE.COM, CalDAVErrFromRefresh=YES, CoreDAVHTTPHeaders=<CFBasicHash 0x7fsnipaac0 [0x7fsnipc440]>{type = immutable dict, count = 18,
entries =>
0 : Content-Type = <CFString 0x7fsnip9860 [0x7fsnipc440]>{contents = “application/json; charset=utf-8”}
1 : Keep-Alive = <CFString 0x7fsnipd080 [0x7fsnipc440]>{contents = “timeout=5, max=97”}
2 : Pragma = no-cache
3 : Content-Security-Policy = <CFString 0x7fsnip4520 [0x7fsnipc440]>{contents = “default-src ‘none’;base-uri ‘none’;manifest-src ‘self’;script-src ‘self’ ‘unsafe-eval’;style-src ‘self’ ‘unsafe-inline’;img-src ‘self’ data: blob:;font-src ‘self’;connect-src ‘self’;media-src ‘self’”}
5 : Set-Cookie = <CFString 0x7fsnip0560 [0x7fsnipc440]>{contents = “ocmsnipdhq7; path=/; secure; HttpOnly, oc_sessionPassphrase=ogK%2snip7z18; path=/; secure; HttpOnly, __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax, __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict”}
6 : Server = <CFString 0x7fsnipa340 [0x7fsnipc440]>{contents = “Apache/2.4.18 (Ubuntu)”}
7 : X-XSS-Protection = <CFString 0x7fsnip36d0 [0x7fsnipc440]>{contents = “1; mode=block”}
8 : Expires = <CFString 0x7fsnipe660 [0x7fsnipc440]>{contents = “Thu, 19 Nov 1981 08:52:00 GMT”}
9 : X-Download-Options = noopen
10 : X-Permitted-Cross-Domain-Policies = none
12 : Cache-Control = <CFString 0x7fsnip1360 [0x7fsnipc440]>{contents = “no-cache, no-store, must-revalidate”}
13 : Date = <CFString 0x7fsnip2960 [0x7fsnipc440]>{contents = “Tue, 13 Mar 2018 21:19:10 GMT”}
14 : X-Robots-Tag = none
15 : Strict-Transport-Security = <CFString 0x7fsnip72a0 [0x7fsnipc440]>{contents = “max-age=15768000”}
16 : Content-Length = 43
17 : Connection = <CFString 0x7fsnipf940 [0x7fsnipc440]>{contents = “Keep-Alive”}
19 : X-Content-Type-Options = nosniff
21 : X-Frame-Options = <CFString 0x7fsnip5420 [0x7fsnipc440]>{contents = “SAMEORIGIN”}
}
}]

hmmm…
Aus der Konsole ist ersichtlich, dass Mac OS den Header empfängt mit einem 401 Status Code, der bedeutet, dass eine Authentifizierung erforderlich ist. Ist ja eigentlich soweit alles richtig.
Hast du Zugriff auf die Logdateien des Webservers? Wäre interessant, was er dazu zu sagen hat. Der 401 ist normal, danach müsste dann nach erfolgreichem Login irgendein 2xx Status code kommen.

Hast du zwischenzeitlich das Passwort des Accounts geändert? Falls ja: lösche den account aus den Systemeinstellungen und alle dazu gehörenden im Schlüsselbund gespeicherten Einträge.

Danach: kannst du nochmal in der bruteforce-Tabelle nachschauen, dass die auch wirklich leer ist und jetzt nichts neues dazugekommen ist (falls da Einträge drin sind, wartet Nextcloud immer länger, bis ein Login erfolgreich ist - dadurch könnte es zu Timout Problemen kommen).

Danach würde ich das Mac OS Kalenderprogramm öffnen und gleichzeitig die Tasten “Cmd”+“r” drücken. Dadurch sollten alle Kalender aktualisiert werden. Im Idealfall verschwindet dann das kleine Dreieck.

  • Auszug aus dem Apache-Log siehe unten
  • Einträge aus dem Schlüsselbund gelöscht
  • Account aus “Kalender” gelöscht
  • Account in “Kalender” neu angelegt (via Autom.)
  • Account wurde erzeugt, aber danach kam wieder die Passwortabfrage
  • oc_bruteforce_attempts war und ist immer noch leer
  • 10.0.3.2 ist die IP des NAT-Adapters der VirtualBox

(Zur besseren Lesbarkeit habe ich bei den folgenden Zeilen den identischen Mittelteil rausgeschnitten)
[Mon Mar 19 14:59:03.604116 2018] [evasive20:error] [pid 12520] [client 10.0.3.2:53084] client denied by server configuration: /var/www/nextcloud/
[Mon Mar 19 14:59:03.697336 2018] --snip-- /var/www/nextcloud/login
[Mon Mar 19 14:59:03.875900 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:04.059732 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:04.139242 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:04.323960 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:04.402595 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:04.595316 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:04.675842 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:04.871940 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:04.947103 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:05.146053 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:05.228554 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:05.420944 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:05.490900 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:05.673188 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:05.756169 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:05.937776 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:06.006342 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:06.226515 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:06.302097 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 14:59:06.493504 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 14:59:06.561046 2018] --snip-- /var/www/nextcloud/
[Mon Mar 19 14:59:06.655586 2018] --snip-- /var/www/nextcloud/login
[Mon Mar 19 14:59:06.781467 2018] --snip-- /var/www/nextcloud/principals
[Mon Mar 19 14:59:06.877916 2018] --snip-- /var/www/nextcloud/login

Nachdem ich den Account gelöscht und erneut angelegt habe:

[Mon Mar 19 15:16:09.945719 2018] [evasive20:error] [pid 920] [client 10.0.3.2:53316] client denied by server configuration: /var/www/nextcloud/remote.php
[Mon Mar 19 15:16:10.133448 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 15:16:10.282640 2018] --snip-- /var/www/nextcloud/remote.php
[Mon Mar 19 15:16:10.460613 2018] --snip-- /var/www/nextcloud/apps/files/
[Mon Mar 19 15:16:10.625946 2018] --snip-- /var/www/nextcloud/
[Mon Mar 19 15:16:10.742473 2018] --snip-- /var/www/nextcloud/login
[Mon Mar 19 15:16:10.887399 2018] --snip-- /var/www/nextcloud/principals
[Mon Mar 19 15:16:10.990820 2018] --snip-- /var/www/nextcloud/login

Das sieht für mich ehrlich gesagt nach einer Misskonfiguration des Webservers aus. Wenn der Zugriff auf die remote.php verboten ist, dann kann die caldav synchronisation nicht funktionieren. Die anderen Zeilen haben nichts mit der caldav-synchronisation zu tun (außer evtl. …/nextcloud/)

Außerdem:
[evasive20:error] [pid 920] [client 10.0.3.2:53316] client denied by server configuration:
hast du durch
--snip--
ersetzt? Verstehe ich das richtig? Dann wundert mich, dass überhaupt irgendetwas geht, denn da werden ja jede Menge Zugriffe verboten.

Bei der Serverkonfiguration kann ich dir leider nicht weiterhelfen, da ich mich nicht mit Apache auskenne. Ich kann dich daher leider nur auf die Doku verweisen:
https://docs.nextcloud.com/server/13/admin_manual/installation/source_installation.html#apache-web-server-configuration

Da ich dasselbe Problem hatte, stieß ich auch auf diesen Thread, der das Problem löst. Der Grund scheint mir zu sein, dass die Anleitung im Handbuch -“Manuell” zu benutzen- nur funktioniert, wenn der Nextcloud-Server NICHT in einem Unterverzeichnis läuft. Mein Server und der des OP laufen aber in “/nextcloud” … das sollte im Handbuch ergänzt werden. Dann braucht man “Erweitert” und gibt als Server NUR dir (Sub-)Domain an, und als Pfad den GESAMTEN Pfad ab dem ersten /. Und als Port 443, klar.

Hi vielen Dank für Deine Hilfe, leider komme ich damit immer noch nicht ans Ziel, bin mir aber nicht sicher, ob ich es korrekt verstanden habe.

Also ich habe Nextcloud im Hauptordner der Domain liegen und nutze auch die Domain und keine Subdomain.

In der Nextcloud finde ich “http://DOMAIN.DE/remote.php/dav/principals/users/USER/

Wenn ich nun im Kalender bin, gehe ich bei Accounts auf ERWEITERT.
Als Benutzername gebe ich USER ein.
Als Passwort das selbe, womit ich mich auch auf der Weboberfläche einlogge.
Serveradresse DOMAIN.DE (ohne http oder so).
Serverpfad: /remote.php/dav/principals/users/USER/

Und ich komme leider nicht rein.

Bei manuell klappt es auch nicht.
Bei meinem Android Handy geht es und mit einer anderen Cloud habe ich es auch schon bei meinem MacOs geschafft.

Würde mich sehr freuen, wenn Du mir helfen könntest.

LG

Hallo mig,
wenn du keine Subdomain nutzt, sollte es auch ohne Klimmzüge (sprich: ohne “Erweitert”) funktionieren. Ich vermute eher, dass dein service-discovery nicht richtig eingestellt ist.
Gruß
Olav

Hallo Olaf,
sehe das du selbiges Problem wie ich hattest. Bevor ich mich mit selbigen an die Community wende, frage ich doch gleich dich, wie ich das Problem gelöst bekomme, da ich mittlerweile etliche Stunden damit verbracht habe. Gehe immer und immer wieder diese Anleitung durch, überprüfe PW und Benutzername, jedoch bekomme ich immer wieder die gleiche Fehlermeldung:
Da ich meinen Mac mit neuem Betriebssystem Big Sure versehen habe, mußte ich die Einstellungen, bzw Anmeldung für Nextcloud Kalender neu einrichten, was “eigentlich” überhaupt kein Problem sein sollte. Nun habe ich gestern den ganzen Nachmittag damit verbracht im Menü von Apple Mail “Neuer Account” “Erweitert” meine Daten einzugeben.
Ich habe vollen Zugriff auf den Nextcloud meines Kollegen, somit kann ich auch in die Sicherheitseinstellungen alles überprüfen. “Hatte” alles mal super geklappt…
1.Benutzername
2. Passwort (zigmal bei Nextcloud überprüft) 3. Serveradresse: nextcloud.(Name).i1box.eu
4. Serverpfad: kopiert aus den Kalender Eigenschaften ganz unten links ( IOS/MacOS Kalender Adressen.
Port 443 und SSL verwenden
Nix geht. Habe alles gedreht und https mal weggelassen, was mir alles so einfiel, alle Möglichkeiten.
Habe auch versucht, ob dies auf einem anderen Apple Rechner zu verwenden.
Immer selbiges Ergebnis: Accountname/Passwort konnte nicht überprüft werden.
Accountname stimmt, Passwort ebenso.
Kannst Du was dazu sagen?

Manno, habs echt hinbekommen wie Du es beschrieben hast, wenn auch ein wenig kryptisch…
Schönen Nicolaus!

Sorry Michael, hab deinen Post eben erst gesehen. Super, dass du es (selbst) hinbekommen hast :slight_smile: