I have an Egroupware 17.1 Community Edition Server. I had it syncing with my old Samsung phone using a different discontinued Sync app. This weekend I got a new Samsung S10 and have been unable to sync it with the Samsung Calendar. I can create a DAVx5 account but only for the address book. The calendar does not show up.
I have also tried other sync apps without sucess.
Maybe internally eGroupware changed the URL settings for the CalDAV part. Which Base URL did you use?
http://egroupware.mydomain.com/egroupware/groupdav.php
If I enter that url into a browser I get a prompt for a username and password.
The carddav uses this url
http://egroupware.mydomain.com/egroupware/groupdav.php/rob/addressbook
There is no calendar
Did you use “groupdav.com” or “groupdav.php” in this URL?
@devvv4ever
Sorry I used groupdav.php
@rsteinmetz70112 said in Sync with Samsung Calendar not working:
http://egroupware.mydomain.com/egroupware/groupdav.com
If I enter that url into a browser I get a prompt for a username and password.
The carddav uses this url
http://egroupware.mydomain.com/egroupware/groupdav.com/rob/addressbook
There is no calendar
Normally this should work in one account. If you send us a test account via email (support-en@bitfire.at) we can look into it.
Or you can try to enable verbose logging and create the account again. Then stop the logging and attach it here.
I don’t think its a problem with the calendar app. DAVx5 must be able to receive the calendar from the server, but it seems in your case only the CardDAV part of egroupware sends the collections back to DAVx5 but the CalDAV part does not. So only the address book is shown in DAVx5…
I tried sending you an email support-en@bitfire.at it bounced.
support-en@bitfire.at: host tyr.dev001.net[144.76.16.37] said: 550 5.1.1
support-en@bitfire.at: Recipient address rejected: User unknown in
virtual mailbox table (in reply to RCPT TO command)
Ah mistyped… It should be support-en@davx5.com 
@devvv4ever
Resent.
Hi,
Thanks for the test account. It seems that the server is misconfigured, probably regarding to permissions. At the initial request to /egroupware/ (which is redirected to /egroupware/groupdav.php/), the server returns two things:
/egroupware/groupdav.php/principals/users/test/,/egroupware/groupdav.php/test/.Note that it doesn’t return a calendar home-set.
When DAVx⁵ lists the resources, it
So DAVx⁵ can only find address book, which is what it does.
I think there are some permission problems. Can you confirm that with the server logs?
I can confirm that there are entries in teh error.log and access.log for Apache2.
That are not very informative here is a sample:
access.log:
root@hamlet:/var/log/apache2# 178.190.217.1 - test [18/Feb/2020:08:30:30 -0600] “PROPFIND /egroupware/groupdav.php/principals/users/test/ HTTP/1.1” 403 264 “-” “DAVx5/2.6.4-beta1 (2020/02/18; dav4jvm; okhttp/3.12.8) Android/10”
178.190.217.1: command not found
root@hamlet:/var/log/apache2# 192.168.1.130 - debbie [18/Feb/2020:11:21:06 -0600] “PROPFIND /egroupware/groupdav.php/principals/users/debbie/ HTTP/1.1” 403 266 “-” “iOS/11.4.1 (15G77) dataaccessd/1.0”
192.168.1.130: command not found
error.log
[Tue Feb 18 09:50:22.249403 2020] [:error] [pid 5105] [client 192.168.1.109:51508] # Instance=default, User=administrator, Request=POST http://egroupware.steinmetznet.com/egroupware/json.php?menuaction=EGroupware\Api\Etemplate\Widget\Nextmatch::ajax_get_rows, User-agent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5 Lightning/5.4, referer: http://egroupware.steinmetznet.com/egroupware/index.php?cd=yes
[Tue Feb 18 11:37:56.640386 2020] [:error] [pid 5038] [client 192.168.1.120:50493] EGroupware\Api\Vfs\Sqlfs\StreamWrapper::dir_opendir(‘links://default/apps/calendar/12459’,0) links://default/apps/calendar/12459 is no directory!, referer: http://egroupware.steinmetznet.com/egroupware/index.php?menuaction=calendar.calendar_uiforms.edit&cal_id=12459&date=2020-07-09T11%3A00%3A00.000Z
I don’t see anyway to change the permissions, except maybe on some .php file I haven’t looked too deeply.
I have discovered that some files are owner by www-data group www-data and other are owned by root group root. That has never been a problem before.
I was able to get a calendar to work using an old app - aCalDav.
@rsteinmetz70112 said in Sync with Samsung Calendar not working:
I was able to get a calendar to work using an old app - aCalDav.
Does it auto-detect collections? If you use that actual calendar paths, you can enter them into DAVx⁵ as well.
But I’d really fix the server problem; if you don’t, you might run into other problems soon.
I’d like to try to fix the server issues, whatever it is, but I don’t know what it is and this server has been in use for years, without apparent problems.
I’ll try to enter that actual paths. Opening groupdav.php and logging in to the server I can see and access them in a web browser.
This just in from Ralf Becker at Egroupware:
Sounds like a wrong URL. “users” is no EGroupware application.
No idea if DAVx5 does an auto-detection and -configuration. If that is the case, like eg. for an iPhone, you just give the server-name, user-name and password and the client does the rest.
Hello,
$ curl -vu test:test -X PROPFIND http:/yourserver/egroupware/groupdav.php/
...
< HTTP/1.1 207 Multi-Status
<D:propstat>
<D:prop>
<D:current-user-principal><D:href>/egroupware/groupdav.php/principals/users/test/</D:href></D:current-user-principal>
<ns2:addressbook-home-set><D:href>/egroupware/groupdav.php/test/</D:href></ns2:addressbook-home-set>
// no calendar-home-set here!
...
The principal URL is usually used to get the home sets, and your server returns /egroupware/groupdav.php/principals/users/test/. How can it return this URL if it doesn’t exist?
For the rest, please see my posting above: the server returned an address book set and no calendar home set. How should DAVx⁵ be able to find the collections?
No idea if DAVx5 does an auto-detection and -configuration. If that is the case, like eg. for an iPhone, you just give the server-name, user-name and password and the client does the rest.
I agree. Yes, DAVx⁵ does auto detection. And no, it can’t do the rest here, because the server returns wrong (principal URL that doesn’t exist) and incomplete (addressbook-home-set, but no calendar-home-set) information.
Regarding auto-discovery: have a look into our manual here for creating well-known paths or SRV/TXT records:
https://www.davx5.com/manual/accounts_collections.html?#how-does-service-discovery-work
It can make things really easy for users 