@rfc2822 Thank you, this was actually the solution! After enabling the android calendar, synchronisation works as it should.
DSM Calendar: alias url not supported
I’ve been unable to have DavDroid access my Synology DSM Calendar using customized URL with alias as it can be set up in DSM settings as displayed here:
This allows to use “https://<fqdn>/calendar/” instead of “https://<fqdn>:<port>/”
That’s not a really big deal but maybe you should investigate.
I had just published another post (which I’ve deleted since) thinking the Synology specific workaround didn’t worked anymore, but further testing as convinced me that te problem is elsewhere.
Using the form <host>:<port> works perfectly so I’m Ok, although I have to open an extra port on my router which I would have liked to avoid.
I think this is a server problem (which doesn’t return the correct path in WebDAV responses). Did you check the logs and contact Synology about that?
Did you check the logs
I did but that’s beyond my skills in this area. I can send you logfiles in private if you’re interested.
and contact Synology about that?
I prefer not to lose much time on this issue by opening a ticket to Synology support since I’ve a workaround. Especially since I’ve already bad experiences with their support team in the past
One time they basically asked to factory reset my NAS as second response to a ticket as a prerequisite to investigate further.
I also remember submitting a support request for an easily reproducible issue (confirmed by other community forum members) and which I even have later been able to demonstrate on their online demo server, and yet being asked to produce a dump of my own NAS (dump which contains sensitive data: I’ve checked) do complete processing my request.
@GPion I see. If there’s any specific indication that this could be a DAVdroid problem, please post it here.
please post it here.
Ok here’s two log files, one produced by a connection attempt not using the “.php” workaround and one which does.
I’ve replaced my domain name (as “my.domain.com”) and user name (“username”) for privacy reasons
@GPion As I have suspected:
2017-04-02 20:48:39 27118 [HttpClient$1] --> PROPFIND https://my.domain.com/calendar/caldav/username http/1.1 […] <multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:A="http://apple.com/ns/ical/"> <response> <href>/caldav.php/username/</href> <propstat> […] 2017-04-02 20:48:40 27118 [dav4android.DavResource] Received <response> for https://my.domain.com/caldav.php/username/
The server replies that it’s located at
/caldav.php/username/. This is the only path that will work (with
.php). It’s a Synology problem.
I’ve even been able to reproduce the issue using online Synology demo server and given that information in the ticket details.
And here’s the answer I’ve obtained:
Per discussion with our engineer, when use the calendar client over the calendar alias to contact it.
Our calendar will auto forward to non-alias to contact, this is the alias limitation.
But your question is only alias can use. We would like know did you have setting other web service or firewall block?
We suggest please use the other port or try use other customized port to use
Not only I don’t fully even understand what he’s saying (“auto forward to non-alias to contact”: what the hell does this means?) but I’m pretty sure they didn’t have fully understood the issue too (and I had given the URL of the current thread in the ticket details though).
So, even if I don’t like it, seem that I’m stuck to using the dedicated port instead of the alias.
I’m still fully convinced Synology devices and software are really great products but support is often abysmal.