CalDAV Probleme

SvenZ 2022-01-10 13:57:27 UTC #1

Hallo und ein gesundes neues Jahr!

Ich habe am Wochenende Egroupware auf Debian 11 eingerichtet und Termine von der Version 16.1 übernommen. Dabei habe ich bewusst nur die Termine als ical exportiert und nicht die gesamt Datenbank. Eigentlich läuft jetzt alles ohne Probleme. Allerdings haben wir ein Problem mit CalDav unter Outlook und Kalendereinträgen. Neue Termine schreiben kann ich, auch Termine löschen, wenn ich jedoch eine Änderung an einem Termin unter Outlook vornehme, dann bekomme ich folgende Fehlermeldung:

CalDavSynchronizer.DataAccess.WebDavClientException: Response status code does not indicate success: ‘403’ (‘Forbidden’). Message:

at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.d__10.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.d__9.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.d__8.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at CalDavSynchronizer.DataAccess.CalDavDataAccess.d__28.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at CalDavSynchronizer.Implementation.CalDavRepository1.<TryUpdate>d__16.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at CalDavSynchronizer.Implementation.CalDavRepository1.d__16.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at GenSync.EntityRepositories.BatchEntityRepositoryAdapter`4.d__3.MoveNext()

Sofern ich das richtig verstehe, dann heißt das, dass ich zum schreiben keine Berechtigung habe. Dies ergibt für mich allerdings keinen Sinn, da ich ja Termine neu erstellen und auch entfernen kann. Eingeloggt bin ich als der User, der den Kalender erstellt hat. Zusätzlich zu meinem Outlook, wird der Kalender unter gleichen Nutzerdaten noch von 6 anderen PCs abgerufen. Allerdings glaub ich nicht, dass es dadurch zu Problemen kommen kann, da es bei der alten Version auch ohne Probleme funktioniert hat. Übersehe ich irgendwas oder könnt Ihr mir mit diesem Problem helfen?

Viele Grüße
Sven

StefanU 2022-01-10 18:58:47 UTC #2

Hallo Sven.

Vorweg:
Ich halte das für keine gute Idee ein EGroupware-Update mit einem Kalender-Re-Import durchzuführen. Insbesondere nicht, wenn da Sync-Client (und dann noch mehrere) dran hängen.

Da sind Datenbank-IDs der Termine, der Benutzer/Gruppen, Besitzer, Sync-Status der Objekte (,…) die unter umständen hinterher nicht mehr zueinander passen.

Besser ist es inplace oder per Backup zu migrieren/upzudaten. Überflüssige Daten kann man vorher/nachher löschen.

Setzt ihr auch andere Clients ein? Wie sieht es da aus?

Das sind Meldungen vom CalDavSynchronizer. Ich denke das wird hier niemand wirklich interpretieren können. Vielleicht im CalDavSynchronizer-Forum?

Du hast durch den Re-Import der Kalenderdateien ja wesentliche Änderungen an der Datenbank vorgenommen. So wirst du beide Versionen nicht vergleichen können.

Schau doch mal in das CalDAV-Log von EGroupware:

Ich denke, da wirst du eher etwas finden. Die Kommunikation ist direkt lesbar und hier sieht man eher, wenn EGw ein Problem mit irgendwelchen Daten hat. Bei Fehlern ist *DAV recht geschwätzig. Auf beiden Seiten.

Ich würde mich aber auch nicht wundern, wenn Outlook (+CalDavSynchronizer) die alten und neuen Daten nicht mehr zusammenbringen mag. Es würde vielleicht helfen Outlook komplett neu zu synchronisieren. Wie auch immer das bei diesem Ding geht…

Stefan

SvenZ 2022-01-10 22:24:12 UTC #3

Hallo Stefan,

erstmal danke für deine schnelle Antwort! ich hab inzwischen noch etwas rumprobiert, um zu sehen, ob ich den Fehler mit einer neuen Installation oder einen Backup reproduzieren kann. Hierfür hab ich einen neuen Debian Server auf einer virtuellen Maschine aufgesetzt, EGroupware installiert (gemäß der Anleitung bei GitHub) und ein Backup der alten Datenbank aufgespielt. Bei einem weiteren Versuch hab ich einfach EGroupware komplett neuinstalliert und versucht mit Outlook zu synchronisieren. Bei allen Versuchen ist der gleiche Fehler aufgetreten: Termine schreiben und löschen ist möglich, Termine ändern nicht. Ich gehe aus diesem Grund davon aus, dass es kein Fehler mit der Datenbank und alten Versionen ist. Ich habe hierfür ein neues Outlook ohne CalDavProfil vom alten Server verwendet und komplett alles neu eingerichtet.

Wir haben derzeit nur Outlook Clients, die auf EGroupware zugreifen

Ich habe den kompletten Log von EGroupware mal angehangen. Ich werde daraus leider nicht schlau, da es den selben Fehler bringt wie CalDav: “403: forbidden”

*** 172.18.0.1 2022-01-10T22:16:08+00:00
REPORT /egroupware/groupdav.php/calendar/ HTTP/1.1
Connection: Keep-Alive
Content-Length: 683
X-Forwarded-Server: 127.0.1.1
X-Forwarded-Host: 192.168.0.64
X-Forwarded-For: 192.168.0.61
Authorization: Basic ***************
Content-Type: application/xml; charset=utf-8
Depth: 1
User-Agent: CalDavSynchronizer/4.1
Host: 192.168.0.64
Content-Length: 683
Content-Type: application/xml; charset=utf-8
<?xml version="1.0"?>
                <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
                    <D:prop xmlns:D="DAV:">
                        <D:getetag/>
                    </D:prop>
                    <C:filter>
                        <C:comp-filter name="VCALENDAR">
                            <C:comp-filter name="VEVENT">
                              <C:time-range start="20211111T000000Z" end="20230111T000000Z"/>
                            </C:comp-filter>
                        </C:comp-filter>
                    </C:filter>
                </C:calendar-query>
HTTP/1.1 207 Multi-Status
Date: Mon, 10 Jan 2022 22:16:08 GMT
Server: nginx/1.20.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Dav-Powered-By: EGroupware 21.1.001 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 207 Multi-Status
DAV: 1, 2, access-control, calendar-access, calendar-auto-schedule, calendar-proxy, calendarserver-principal-property-search, calendarserver-private-events, calendar-managed-attachments
Content-Type: text/xml; charset=“utf-8”
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D=“DAV:”>
<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/egroupware/groupdav.php/calendar/bb7335d6-4a9c-4847-bafd-0d0d9d92b76f.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>“101:0:1641852553”</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/egroupware/groupdav.php/calendar/bb7335d6-4a9c-4847-bafd-0d0d9d92b76f.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>“102:0:1641852553”</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/egroupware/groupdav.php/calendar/bb7335d6-4a9c-4847-bafd-0d0d9d92b76f.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>“103:0:1641852553”</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/egroupware/groupdav.php/calendar/6706a578-cd86-4992-9947-9f053449fd82.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>“152:0:1641852557”</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/egroupware/groupdav.php/calendar/040000008200E00074C5B7101A82E00800000000F0D5344E7706D801000000000000000010000000E46E9696E5DB404FA56D52CF7D7BE821.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>“200:0:1641852652”</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/egroupware/groupdav.php/calendar/6706a578-cd86-4992-9947-9f053449fd82.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>“153:0:1641852557”</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
*** REPORT calendar-query /calendar/ --> “207 Multi-Status” took 0.003 s

*** 172.18.0.1 2022-01-10T22:16:08+00:00
REPORT /egroupware/groupdav.php/calendar/ HTTP/1.1
Connection: Keep-Alive
Content-Length: 611
X-Forwarded-Server: 127.0.1.1
X-Forwarded-Host: 192.168.0.64
X-Forwarded-For: 192.168.0.61
Authorization: Basic ***************
Content-Type: application/xml; charset=utf-8
Depth: 1
User-Agent: CalDavSynchronizer/4.1
Host: 192.168.0.64
Content-Length: 611
Content-Type: application/xml; charset=utf-8
<?xml version="1.0"?>
  	                    <C:calendar-multiget xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
  	                        <D:prop>
  	                            <D:getetag/>
  	                            <D:displayname/>
  	                            <C:calendar-data/>
  	                        </D:prop>
                                    <D:href>/egroupware/groupdav.php/calendar/040000008200E00074C5B7101A82E00800000000F0D5344E7706D801000000000000000010000000E46E9696E5DB404FA56D52CF7D7BE821.ics</D:href>
                                </C:calendar-multiget>
HTTP/1.1 207 Multi-Status
Date: Mon, 10 Jan 2022 22:16:08 GMT
Server: nginx/1.20.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Dav-Powered-By: EGroupware 21.1.001 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 207 Multi-Status
DAV: 1, 2, access-control, calendar-access, calendar-auto-schedule, calendar-proxy, calendarserver-principal-property-search, calendarserver-private-events, calendar-managed-attachments
Content-Type: text/xml; charset=“utf-8”
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D=“DAV:”>
<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/” xmlns:ns2=“urn:ietf:params:xml:ns:caldav”>
<D:href>/egroupware/groupdav.php/calendar/040000008200E00074C5B7101A82E00800000000F0D5344E7706D801000000000000000010000000E46E9696E5DB404FA56D52CF7D7BE821.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>“200:0:1641852652”</D:getetag>
ns2:calendar-dataBEGIN:VCALENDAR
VERSION:2.0
PRODID:-//EGroupware//NONSGML EGroupware Calendar 21.1//EN
BEGIN:VEVENT
DTSTART;VALUE=DATE:20220111
DTEND;VALUE=DATE:20220112
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
X-MICROSOFT-CDO-BUSYSTATUS:FREE
SUMMARY:test
PRIORITY:5
TRANSP:TRANSPARENT
UID:040000008200E00074C5B7101A82E00800000000F0D5344E7706D801000000000000000
010000000E46E9696E5DB404FA56D52CF7D7BE821
STATUS:CONFIRMED
CREATED:20220110T221052Z
LAST-MODIFIED:20220110T221052Z
DTSTAMP:20220110T221608Z
END:VEVENT
END:VCALENDAR
</ns2:calendar-data>
<D:displayname>test</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
*** REPORT calendar-multiget /calendar/ --> “207 Multi-Status” took 0.007 s

*** 172.18.0.1 2022-01-10T22:16:08+00:00
PUT /egroupware/groupdav.php/calendar/040000008200E00074C5B7101A82E00800000000F0D5344E7706D801000000000000000010000000E46E9696E5DB404FA56D52CF7D7BE821.ics HTTP/1.1
Connection: Keep-Alive
Content-Length: 890
X-Forwarded-Server: 127.0.1.1
X-Forwarded-Host: 192.168.0.64
X-Forwarded-For: 192.168.0.61
Authorization: Basic ***************
Content-Type: text/calendar; charset=utf-8
If-Match: "200:0:1641852652"
User-Agent: CalDavSynchronizer/4.1
Host: 192.168.0.64
Content-Length: 890
Content-Type: text/calendar; charset=utf-8

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ddaysoftware.com//NONSGML DDay.iCal 1.0//EN
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYHOUR=3;BYMINUTE=0;BYMONTH=10
TZNAME:Mitteleuropäische Zeit
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYHOUR=2;BYMINUTE=0;BYMONTH=3
TZNAME:Mitteleuropäische Sommerzeit
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CLASS:PUBLIC
DESCRIPTION:
DTEND;VALUE=DATE:20220112
DTSTAMP:20220110T221610Z
DTSTART;VALUE=DATE:20220111
PRIORITY:5
SEQUENCE:1
SUMMARY:test 2
TRANSP:TRANSPARENT
UID:040000008200E00074C5B7101A82E00800000000F0D5344E7706D801000000000000000
010000000E46E9696E5DB404FA56D52CF7D7BE821
X-MICROSOFT-CDO-BUSYSTATUS:FREE
END:VEVENT
END:VCALENDAR

HTTP/1.1 403 Forbidden
Date: Mon, 10 Jan 2022 22:16:08 GMT
Server: nginx/1.20.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Dav-Powered-By: EGroupware 21.1.001 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 403 Forbidden

PUT /calendar/040000008200E00074C5B7101A82E00800000000F0D5344E7706D801000000000000000010000000E46E9696E5DB404FA56D52CF7D7BE821.ics --> “403 Forbidden” took 0.003 s

*** 172.18.0.1 2022-01-10T22:16:08+00:00
DELETE /egroupware/groupdav.php/calendar/bb7335d6-4a9c-4847-bafd-0d0d9d92b76f.ics HTTP/1.1
Connection: Keep-Alive
Content-Length: 0
X-Forwarded-Server: 127.0.1.1
X-Forwarded-Host: 192.168.0.64
X-Forwarded-For: 192.168.0.61
Authorization: Basic ***************
If-Match: "101:0:1641852553"
User-Agent: CalDavSynchronizer/4.1
Host: 192.168.0.64
Content-Length: 0
Content-Type:

HTTP/1.1 412 Precondition Failed
Date: Mon, 10 Jan 2022 22:16:08 GMT
Server: nginx/1.20.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Dav-Powered-By: EGroupware 21.1.001 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 412 Precondition Failed
*** DELETE /calendar/bb7335d6-4a9c-4847-bafd-0d0d9d92b76f.ics --> “412 Precondition Failed” took 0.002 s

*** 172.18.0.1 2022-01-10T22:16:08+00:00
DELETE /egroupware/groupdav.php/calendar/6706a578-cd86-4992-9947-9f053449fd82.ics HTTP/1.1
Connection: Keep-Alive
Content-Length: 0
X-Forwarded-Server: 127.0.1.1
X-Forwarded-Host: 192.168.0.64
X-Forwarded-For: 192.168.0.61
Authorization: Basic ***************
If-Match: "152:0:1641852557"
User-Agent: CalDavSynchronizer/4.1
Host: 192.168.0.64
Content-Length: 0
Content-Type:

HTTP/1.1 412 Precondition Failed
Date: Mon, 10 Jan 2022 22:16:08 GMT
Server: nginx/1.20.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Dav-Powered-By: EGroupware 21.1.001 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 412 Precondition Failed
*** DELETE /calendar/6706a578-cd86-4992-9947-9f053449fd82.ics --> “412 Precondition Failed” took 0.002 s

RalfBecker 2022-01-11 07:50:58 UTC #4

Kannst Du mal versuchen als Kalender URL statt https://example.org/egroupware/groupdav.php/calendar/ den Benutzernamen mitzugeben https://example.org/egroupware/<user>/groupdav.php/calendar/.

Deine Schreibweise ohne Benutzername wird zwar noch unterstützt, ist aber nicht aktuell, damit kannst Du auch nicht auf die Kalender anderer Benutzer zugreifen.

Ich denke mal das Problem hat nichts mit der Art der Migration zu tun.
Wie Stefan kann ich nur ausdrücklich dazu raten, das Update über die Datenbank zu machen, und nicht per iCal o.ä…

Ralf

SvenZ 2022-01-11 11:06:02 UTC #5

Hallo Ralf,

den Vorschlag war die Lösung. Jetzt ist alles wieder wie gewohnt möglich, vielen vielen Dank! eine kleine Anmerkung: die richtige Adresse ist https://example.org/egroupware/groupdav.php/<user>/calendar/.

Für die nächste Migration, sollte sie denn notwendig sein, werde ich die komplette Datenbank übernehmen. Bis jetzt hatten wir EGroupware nur als Kalender genutzt. Es wurde von einem meiner Vorgänger eingerichtet und keiner wusste, was damit alles möglich ist. Leider wurde auch das OS nicht gepflegt, wodurch halt alles sehr veraltet war. Ich bin nur froh, dass der PC keinen Internetzugang hatte. Jetzt wollen wir Egroupware viel ausgiebiger nutzen und ich bin derzeit dabei mir erstmal die Grundlagen anzulesen.

Viele Grüße
Sven

StefanU 2022-01-11 19:33:05 UTC #6

Hallo Sven.

Na, da kann ich doch ein wenig nachhelfen:

Webseite Anwendungen:

Übersicht Vorträge (Videos/Folien/QA):

Diverse Flyer (Handouts für OSS-Veranstaltungen):
https://www.egroupware.org/de/community#downloads

Announcements:

Die letzten Release Notes:

Und was danach geschah:

Screenshots zur Collabora Integration:

Da fehlen noch die letzten Entwicklungen. Diese finden sich in den letzten Release Notens und den Vorträgen der COOLDays.

Beschreibung/Screenshots im Univention-App-Center:

Da sollten genug Anregungen dabei sein

Für Business-Anwender wären die Telefon-Integration und das Kanban-Board hoch interessant!

Für Professionellen Support, EPL-Lizenzen, Collabora-Online-Lizenzen, EGroupware als SaaS, …
=> https://www.egroupware.org/de/kontakt

Stefan

SvenZ 2022-01-12 10:08:52 UTC #7

Hallo Stefan,

vielen Dank für die vielen Informationen. Da werde ich mich die nächsten Tage durcharbeiten. Leider ist das nächste Problem aufgetreten… Und zwar werden ganztägige Termine über zwei Tage angezeigt. Die Ursache habe ich inzwischen herausgefunden: in Docker ist als Standardzeit UTC angegeben, sowohl in der Datenbank als auch beim egroupware selbst. Das Problem ist bereits hier beschrieben. Leider schaffe ich es derzeit nicht in Docker die php.ini zu ändern. Könntet ihr mir nochmal eine kleine Hilfestellung geben?

EDIT: ok, das Problem ist doch etwas anders. Ein Update der Serverzeit hat nur dazu geführt, dass alle Termine, sobald eine Synchronisation durchgeführt wurde, erneut eingetragen wurden. Das Problem ist, dass bei Outlook neu eingetragene ganztägige Termine bei einem anderen Rechner als zweitätiger Termin angezeigt werden, bei egroupware als eintätiger Termin. Wenn ich den Termin bei Egroupware öffne, auf speichern klicke und wieder schließe, dann wird er auch bei outlook als eintägiger Termin angezeigt.

EDIT 2: Ich hab inzwischen zumindest einen “workaround” gefunden. Wenn ich als Zeit bei dem “Kalender-Benutzer” UTC einstelle, dann wird alles richtig übernommen.

Viele Grüße
Sven