Can't connect to owncloud calendar from iphone



I'm trying to connect to the calendar app from an iphone.

I create a new calendar calDav account on the iphone, and I then enter:
- server: https://SERVERNAME/owncloud/remote.php/caldav/principals
- username and password

The phone verifies the credentials and tells me that everything is fine.

But when I open the Calendar app, I see no meetings. Also, I cannot create meetings (the "+" symbol to create an event is grayed-out)

I also tried to enter this string as server:

The iphone seems to like this address also, and tells me that everything is fine.
But still I see not meeting and cannot create events.

Thanks for your help


I've got exactly the same issue, however, this all worked for me before I upgraded Fedora 25 to 26. I assume it upgraded Owncloud binaries at the same time from the Fedora repositories. I think something broke with the carddav and caldav integration in the latest 9.1.5 release.

my web interface in a browser works fine with carddav contacts and my calendar. I can update a contact in my owncloud installation, and it gets puched to my iPhone 5s IOS 10.3, but I cannot get changes to contacts in iPhone to propagate back to my server, and calendar does not show up at all in iPhone.


Curious.. My system is a Rapsbian (probably outdated) but I'm running owncloud 10.0.2 and the latest iOS..
My web interface works good as well, and I still didn't try with the contacts.


... the owncloud calendar setup works very well on an android device. it is therefore a problem with the shitty iphone.


Really!? How do you add the CalDAV account on Android? I do have an android device and tried to test this to see if it was a problem with my server or just a "device issue" but couldn't figure out how to add a CalDAV account to Google Calendar.


Not to google calendar, but to an android phone.
I'm using a caldav adapter (can't recall the name right now, sorry) that you can use to create a calendar account.
You can then use the standard calendar app on the phone to link to your owncloud calendar.
I personally prefer the "aCalendar" app though :slight_smile:


I tested going through the web browser and checking the access logs of my web server (nginx). It behaves strangely...

When Accessing from the iPhone (I enter the caldav details ) and then press Done which tests the connection, I get a 401 (request for authentication), then a response of 404 (not found) in the logs: - - [18/Aug/2017:10:30:12 +0200] "PROPFIND /owncloud/remote.php/dav/principles/users/andrew/ HTTP/1.1" 401 426 "-" "iOS/10.3.3 (14G60) accountsd/1.0" "-" - andrew [18/Aug/2017:10:30:13 +0200] "PROPFIND /owncloud/remote.php/dav/principles/users/andrew/ HTTP/1.1" 404 6896 "-" "iOS/10.3.3 (14G60) accountsd/1.0" "-"

But when I log in with a web browser, I see the following: - - [18/Aug/2017:10:34:07 +0200] "GET /owncloud/index.php/apps/calendar/ HTTP/2.0" 200 56773 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - - [18/Aug/2017:10:34:08 +0200] "GET /owncloud/index.php/core/js/oc.js?v=746351c1f8e16db5453b23da128b972e HTTP/2.0" 200 3290 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - - [18/Aug/2017:10:34:09 +0200] "GET /owncloud/index.php/avatar/andrew/64 HTTP/2.0" 200 2984 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - - [18/Aug/2017:10:34:09 +0200] "GET /owncloud/cron.php HTTP/2.0" 200 478 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - andrew [18/Aug/2017:10:34:09 +0200] "PROPFIND /owncloud/remote.php/dav HTTP/2.0" 207 939 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - - [18/Aug/2017:10:34:09 +0200] "POST /owncloud/index.php/apps/calendar/v1/config HTTP/2.0" 200 451 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - - [18/Aug/2017:10:34:09 +0200] "GET /owncloud/index.php/apps/calendar/v1/timezones/EUROPE/BERLIN.ics HTTP/2.0" 200 836 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - - [18/Aug/2017:10:34:09 +0200] "GET /owncloud/ocs/v2.php/apps/notifications/api/v1/notifications?format=json HTTP/2.0" 200 561 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - andrew [18/Aug/2017:10:34:09 +0200] "PROPFIND /owncloud/remote.php/dav/principals/users/andrew/ HTTP/2.0" 207 950 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - andrew [18/Aug/2017:10:34:10 +0200] "PROPFIND /owncloud/remote.php/dav/calendars/andrew/ HTTP/2.0" 207 11511 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - andrew [18/Aug/2017:10:34:10 +0200] "REPORT /owncloud/remote.php/dav/calendars/andrew/personal/ HTTP/2.0" 207 14297 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - andrew [18/Aug/2017:10:34:10 +0200] "REPORT /owncloud/remote.php/dav/calendars/andrew/contact_birthdays/ HTTP/2.0" 207 2063 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-" - andrew [18/Aug/2017:10:34:11 +0200] "PROPFIND /owncloud/remote.php/webdav/ HTTP/1.1" 207 375 "-" "Mozilla/5.0 (Windows) mirall/2.3.2 (build 6928)" "-"

notice how it gives a 20x response (valid success) for every single variation of the webdav/dav/caldav addresses. It's giving valid responses to a webbrowser but a 404 not found when coming in from an iPhone: - andrew [18/Aug/2017:10:30:13 +0200] "PROPFIND /owncloud/remote.php/dav/principles/users/andrew/ HTTP/1.1" 404 6896 "-" "iOS/10.3.3 (14G60) accountsd/1.0" "-" - andrew [18/Aug/2017:10:34:09 +0200] "PROPFIND /owncloud/remote.php/dav/principals/users/andrew/ HTTP/2.0" 207 950 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" "-"

Then I notice the difference! See the two lines above? First one from iPhone, second one from web browser... the web browser used HTTP/2.0, whereas the iPhone used HTTP/1.1. Could this be the issue?


more weirdness; when I test the address (.../owncloud/remote.php/dav/calendars/andrew/personal) from the iPhone, then I get a full stack of successful responses even on HTTP/1.1 from iPhone: - - [18/Aug/2017:10:55:36 +0200] "PROPFIND /owncloud/remote.php/dav/calendars/andrew/personal/ HTTP/1.1" 401 426 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" "-" - andrew [18/Aug/2017:10:55:36 +0200] "PROPFIND /owncloud/remote.php/dav/calendars/andrew/personal/ HTTP/1.1" 207 1868 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" "-" - andrew [18/Aug/2017:10:55:36 +0200] "OPTIONS /owncloud/remote.php/dav/calendars/andrew/personal/ HTTP/1.1" 200 0 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" "-" - - [18/Aug/2017:10:55:37 +0200] "REPORT /owncloud/remote.php/dav/principals/groups/ HTTP/1.1" 200 780 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" "-" - andrew [18/Aug/2017:10:55:38 +0200] "OPTIONS /owncloud/remote.php/carddav/principals/andrew/ HTTP/1.1" 200 0 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" "-" - andrew [18/Aug/2017:10:55:38 +0200] "PROPFIND /owncloud/remote.php/carddav/principals/andrew/ HTTP/1.1" 207 1206 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" "-" - andrew [18/Aug/2017:10:55:39 +0200] "PROPFIND /owncloud/remote.php/carddav/addressbooks/andrew/ HTTP/1.1" 207 3486 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" "-"

Not a single 404 to be found...But the calendar just doesn't sync, despite all the success responses. I suspect that Owncloud itself just doesn't work on this address from an iPhone. I'm starting to think this is just a bug in Owncloud, and that it should work on the /owncloud/remote.php/dav/principles/users/andrew address, but for some reason, just doesn't anymore.


i've probably not got the same issue...

running journalctl -f showed lots of the following:

ownCloud[2479]: {PHP} Doctrine\DBAL\DBALException: Failed to connect to the database: connection refused.

Turned out that when I upgraded my postgres database it reset the listening_adress parameter so nothing was connecting. Extremely weird that I was still able to connect in the web interface. Then I saw messages about PHP-FPM, but I googled the error and was able to fix that as well. Now I don't see any errors anywhere, and my CardDAV contacts are synching both ways, but calDAV calendar still does not work on iPhone.


great insights.. I'll do some testing tonight and I'll take a look at the logs.. Will keep you posted :slight_smile:


Now this is the log when I push a syncronization from an android device. As you see I'm using the CalDAV Sync adapter.
The sync works, and I can also add or remove events in the calendar. - - [18/Aug/2017:19:13:18 +0000] "PROPFIND /owncloud/remote.php/caldav/principals HTTP/1.1" 401 366 "-" "CalDAV Sync Adapter (Android) h ttps:// Version:1.8.1" - john [18/Aug/2017:19:13:20 +0000] "PROPFIND /owncloud/remote.php/caldav/principals HTTP/1.1" 405 307 "-" "CalDAV Sync Adapter (Android) h ttps:// Version:1.8.1" - john [18/Aug/2017:19:13:21 +0000] "PROPFIND /owncloud/remote.php/caldav/principals HTTP/1.1" 207 572 "-" "CalDAV Sync Adapter (Android) h ttps:// Version:1.8.1" - john [18/Aug/2017:19:13:22 +0000] "PROPFIND /owncloud/remote.php/caldav/principals/john/ HTTP/1.1" 207 467 "-" "CalDAV Sync Adapter (Android) h ttps:// Version:1.8.1" - john [18/Aug/2017:19:13:23 +0000] "PROPFIND /owncloud/remote.php/caldav/calendars/john/ HTTP/1.1" 207 1798 "-" "CalDAV Sync Adapter (Android) h ttps:// Version:1.8.1"

These log entries are created when I open the calendar app in iOS. By the way, I just upgraded to iOS 10.3.3.
It looks to me that all the URLs are wrong.. - - [18/Aug/2017:19:13:49 +0000] "PROPFIND /.well-known/caldav HTTP/1.1" 405 166 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" - - [18/Aug/2017:19:13:49 +0000] "PROPFIND / HTTP/1.1" 405 166 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" - - [18/Aug/2017:19:13:49 +0000] "PROPFIND /principals/ HTTP/1.1" 405 166 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0" - - [18/Aug/2017:19:13:49 +0000] "PROPFIND /calendar/dav/john/user/ HTTP/1.1" 405 166 "-" "iOS/10.3.3 (14G60) dataaccessd/1.0"


I read something somewhere about the Rewrite Engine (Apache) and writing a rule for the .well-known addresses. I use nginx so the syntax is not the same and rewrite engine is on by default in nginx. I haven't figured out how to write in a similar rule for these addresses. Could it be that you need to create those rules so it looks at the correct urls?

I've now got no errors anywhere in my logs for nginx, php-fpm, postgresql or journalctl, but still no luck. I do get one weird thing happening when i delete the caldav account in iPhone and try to recreate it...It complains about the SSL certificate. I use Let's Encrypt as my provider and have it setup nicely. I just renewed my cert and it seems to be working perfectly. I use as my DynDNS provider, and have a domain address. The funny thing is that the iPhone says that the certificate that I am trying to use fails verification and that it is from Fortinet in California. No mention of Let's Encrypt, and no mention of the german issued certificates for the main domain that has registered (just in case it didn't like me trying to generate a certificate for a subdomain for an already existing domain). I fgind that very strange and im not sure if thats the reason for the failure or even how to fix it.


I'm also using nginx, and I'm also accessing through a domain name I bought.. and everything seems to be set up properly. My certificate seems to work as intended and I never receive any complain from the iphone.. I run a website security test through an online service (can't recall the name of the service) and everything passed the tests.

I was also thinking to tweak a little bit the server side.. I was thinking if creating ad-hoc folders that link to the actual content of the owncloud folder would help. No idea otherwise how to address the issue..


I think it seems very likely a bug with Owncloud rather than my postgres/nginx/certificate installations.

I tried using CalDAV Sync on Android, and it works perfectly with my server just the way it is. Of course, Android uses the "Primary CalDAV Address" according to Owncloud settings. This was able to sync everything using that /owncloud/remote.php/dav address, when connected remotely.

When syncing with iPhone it uses /owncloud/remote.php/dav/principles/users/MYUSER as the address, and I see references to the ".well-known/caldav" url in nginx logs, which leads me to think that something might be fubar'ed with the .well-known address that is used internally by Owncloud when coming from an IOS. Maybe it got messed up during an upgrade, or maybe hardly anyone uses iPhone CalDAV sync with Owncloud, otherwise you'd think it would be a bigger problem in these forums.

I'm going to take another look at the .well-known nginx rewrite rules to see if anything comes up.

As a side note, another weird thing was that when adding IOS caldav account remotely, it thought my certificate was issued by Fortinet. When adding the account on my LAN, it correctly identified certificate issuer as Let's Encrypt. Weird anomaly.


I added this rule to nginx.conf:

rewrite ^/.well-known/caldav(.*)$ /remote.php/dav$1 redirect;

and I no longer get any 404 errors in /var/log/nginx/access.log, but I do get a load of 405 errors now, and calendar still doesn't work.

Something that looks interesting, is using the following curl statement to get a result from the website:

curl -kl

will give you the html output, but if you try to run the same command by adding "dav" to the end of that address, you get an error message that could be a clue:

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="">
  <s:message>No 'Authorization: Basic' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is mis-configured</s:message>

So... tried adding auth config to nginx.conf using the same credentials for owncloud but just get "forbidden" errors then:

auth_basic "Owncloud Restricted";
auth_basic_user_file /etc/nginx/default.conf/.htpasswd;

curl -kl
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>


Looks like you are running ownCloud in a subdir and not in webroot. The .well-known redirection must then be (note the /owncloud/ before remote.php):
rewrite ^/.well-known/caldav(.*)$ /owncloud/remote.php/dav$1 redirect;
Same redirect is needed for carddav: just replace caldav with carddav.

EDIT: and delete the authentication-stuff from nginx config. The client needs to send authentication:
Username+Password need to be from a valid ownCloud user.
Server reply should be: "This is the WebDAV Interface. It can only be accessed by....."


thanks for the clarification! I added the rewrite as you suggested and re-tried curl using your syntax and got the correct response. However, I then deleted the rewrite rule, restarted nginx and tested the same curl -k -u username:password syntax again, and it does work correctly even without the rewrite rule... so it isn't that thats the problem :confused:

Thanks anyway. Note that my carddav is working perfectly, even bi-directionally, it's just caldav that has stopped working, and it removed all calendar events from iPhone calendar and now refuses to authenticate the connection details when using the /owncloud/remote.php/dav/priciples/users/MYUSER url. It seems that it's JUST that url that's broken, because just pointing it to "/owncloud/remote.php/dav" and leaving it at that does authenticate in the iPhone, but thats not the location of the calendar when coming from an iPhone and even if it lets me add the account, the calendar does not sync, but the "dav" address does work correctly using android caldav sync.


Whether that link works or not has absolutely nothing to do with the rewrite rule.
BUT: the iPhone-Sync has indeed to do with the rewrite rule.
I suggest you try the following:

  1. delete the not working caldav account from your iPhone

  2. add following lines to the nginx-configuration within the "server context" (server {...}) of the server which is running ownCloud. (this adds the ./well-known redirects):
    location = /.well-known/carddav {
    return 301 $scheme://$host/owncloud/remote.php/dav;
    location = /.well-known/caldav {
    return 301 $scheme://$host/owncloud/remote.php/dav;

  3. reload nginx-configuration (nginx -s reload)

  4. check whether the redirect works with:
    curl -kI
    In the servers reply there should be the line:
    If that line is not there, you need to work on setting up the redirect properly. That nginx-configuration example might help:

  5. add the caldav account to your iPhone, using only the domain(!) for the server-field (in your example that should be: Don't add a subdirectory or any other links. Only the domain of the server is needed (and of course username+password)!

  6. touch "save" and wait until all fields are checked from iOS

  7. Open the calendar-app on the iPhone and watch events coming in during the next couple of minutes.

The same approach works for carddav.

P.S.: if you also want to use caldav/carddav on a mac and service-discovery with /.well-known redirects is working:
1. add caldav account
2. choose automatic as account-type and as email-address use (this doesn't have to be a valid email-address and again: only the domain is needed!)


oh yeah!! :slight_smile:
thanks gazillion! I was just trying not to get crazy with the 'rewrite' function :slight_smile:


Hi, last post, I've had it with this now (but it is solved for me so I post my fix here)...

I thought i'd uninstall, but uninstall postgresql wiped out half my installation because of "dependants", so I ended up reinstalling the whole damn OS.

I then had to do a from scratch Owncloud installation (my notes here)

Owncloud installation

sudo -i

dnf install postgresql nginx owncloud-nginx owncloud-postgresql owncloud-client-nautilus

# copy nginx.conf file and Letsencrypt certs from backup
systemctl enable --now nginx php-fpm

postgresql-setup initdb
systemctl enable --now postgresql
setsebool -P httpd_can_network_connect_db on

su - -c "psql" postgres
CREATE USER finite9 WITH PASSWORD 'secret password';
ALTER DATABASE owncloud OWNER TO finite9;

\password postgres

vi /var/lib/pgsql/data/pg_hba.conf
host    all             all             localhost		trust

vi /var/lib/pgsql/data/postgresql.conf

uncomment listen_address and port

vi /etc/owncloud/forcessl.config.php

$CONFIG = array (
  'forcessl' => true,

Vi /etc/owncloud/config.php

# add the following

    1 => '',
    2 => '',

# now set selinux context permissions as root

semanage fcontext -a -t httpd_sys_rw_content_t '/var/lib/owncloud/data(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/lib/owncloud/config(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/lib/owncloud/apps(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/lib/owncloud/assets(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/lib/owncloud/.htaccess'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/lib/owncloud/.user.ini'

restorecon -Rv '/var/lib/owncloud/'

# enable owncloud updates via web interface, but disable after use
setsebool httpd_unified on

# navigate to localhost/owncloud to run the setup wizard
# note that this needs to be done on the non-ssl version of the page on localhost
# note that for this to work, pg_hba.conf MUST use address "localhost" and not

Once the setup wizard has created the ocadm user , and BEFORE logging in, reset pg_hba.conf to:
local   all             all                                     peer
# IPv4 local connections:
host    all             all             localhost		trust
# IPv6 local connections:
host    all             all             ::1/128                 ident

Turn on forcessl and edit the owncloud.conf file in /etc/owncloud

edit the host firewall and allow http and https

then restart nginx and postgresql and re-connect to the web interface using the https public address, not "localhost"

then I had to re-enable to contacts and calendar app in Owncloud. I thought at this point that maybe I should have tried just uninstalling the apps within OC instead, then re-adding them, in case the app itself was outdated for that newer version of owncloud.

Then I re-imported my saved contacts and calendar, tested contacts bi-directionally and they still work, added calDAV address in iPhone and guess what.... I'd been typing the god damn wrong address. "PRINCIPLES" is an English word which came naturally to me, whereas the correct, for Owncloud "PRINCIPALS" in the address was not natural for me. When i used principals, iPhone said it was all good and calendar now syncs in iPhone. I wonder if this was my problem all along :frowning:

correct address is This url is listed in the web interface of the calendar under the settings icon.

Hope some of this helps you in case you have different issue. By the way, all of that rewrite rule stuff was completely unnecessary for me, even when not having OC in webroot.