Synchronize with Radicale CalDAV/CardDAV

This page was developed from the thread below:

"syncevolution and a radicale caldev server" mail thread](

This work is based on syncing the calendaring system on a Nokia n900 to a “Radicale” CalDAV server. Thanks to Patrick for helping me overcome my fondness for typos and following outdated guides …

This is work in progress and hopefully in a few days the two-way sync problem will be resolved. The current version (1.2.2) of SyncEvolution does not play well with a bug in the radicale server – radicale adds extra “/” characters to some paths causing syncevolution to fail. At this point, only a sync from radicale to the n900 is possible so changes made on the n900 can't be pushed back to radicale. This being addressed.

The n900 can have a number of calendars installed – examples might be personal ones for each family member, and online work related and organisational ones such as exchange for an employer/business. The n900 also has a number of built in calendars such as “smart birthdays”. Unfortunately the n900 doesn't come with an easy way to sync these local calendars across your other devices which is where “radicale” comes in. There are other CalDAV servers available, but radicale is easy and simple to get going. There are a lot of outdated guides to SyncEvolution on the web – syntax and capabilities have changed a lot over time and a first time user will get very confused – read the correct documentation for the versions you are using, especially SyncEvolution!

First, get radicale (“”) installed on a server if you do not have one already available. The version I used was 6.4 (latest at this time), version 6.2 didn't work. The basic configuration uses no authentication but radicale can use ssl for transport and htpasswd style authentication. In my case I am using htpasswd (crypt) but not ssl and radicale is working well with lightning (calendar client for the thunderbird mail reader), ipad, iphones and evolution.

The configuration shown here is to synchronise the local calendars – I would recommend avoiding the others in case it goes wrong! An email to the SyncEvolution list also recommended avoiding the “smart birthdays” calendar as its likely to have been “created” on the fly from address information. It is also recommended to avoid read-only calendars (two-way sync) because SyncEvolution is not currently aware of read-only status and may try and write to them.

SyncEvolution can be viewed as a conduit/converter between different calendaring systems, in our case one local and the other remote. Each calendaring system has a number of databases (one for each calendar) so you need to tell it how the local system and databases relate to the remote system and its databases (i.e., map one to the other).


Server – the machine that SyncEvolution is running on (the n900 in our case) – radicale is the “client” – makes sense rom the developers viewpoint but confusing for the user as syncing from the “client” actually means “radicale”. This is likely to change in upcoming versions of SyncEvolution and the developers mention that it is often unclear which is the client and which the server (hence the current action).

First, we need to tell SyncEvolution on the n900 how it it is going to reach the radicale client:

syncevolution --configure \ 
              --template webdav \ 
             username=[htpasswd user] \ 
             password=[htpasswd password] \ 
             syncURL=http://moriah.lan.localdomain:5232/ \ 

Explanation: uses the webdav template which includes the CalDAV settings username and password were created by the apache htpasswd utility – I set up radicale to use htpassword with crypt authentication radicale is running at port 5232 on the host moriah.lan.localdomain target-config – its a remote configuration target named “radicale” The name is a label for referencing this configuration by SyncEvolution and does not have to match the server.

Now we need to tell SyncEvolution about the remote databases (or calendars) we want to sync:

syncevolution --configure \ 
             database=http://moriah.lan.localdomain:5232/[user]/[first_calendar_name]/ \ 
             backend=caldav \ 
             target-config@radicale calendar1 

syncevolution --configure \ 
             database=http://moriah.lan.localdomain:5232/[user]/[second_calendar_name]/ \ 
             backend=caldav \ 
             target-config@radicale calendar2 

syncevolution --configure \ 
             database=http://moriah.lan.localdomain:5232/[user]/[third_calendar_name]/ \ 
             backend=caldav \ 
             target-config@radicale calendar3 

Explanation: radicale organises its storage from a “root_of_storage/user_name/calendar_name” perspective so a real database line for me, “billk”, with a radicale login of “billk” to access my “fishing” calendar would be: database=http://moriah.lan.localdomain:5232/billk/fishing/ \ ** important: note the trailing “/” after “fishing” - required! The “target-config@radicale” references our first stanza where we told SyncEvolution the “syncURL” calendar3 is a name/label that refers to (in this case) “third_calendar_name” which might be named Bill or fishing on the n900 – match your calendar names.

Next we need to connect these remote calendars with local databases. This is done by defining a "sync configuration":

syncevolution --configure \ 
             --template SyncEvolution_Client \
             sync=none \
             syncURL=local://@radicale \
             username= \
             password= \

Then add calendars:

syncevolution --configure \ 
             sync=two-way \
             backend=calendar \
             radicale calendar1

... same for other calendars...

Calendars needs to be created locally first, using the native UI. If unsure about what to put after "database", then run "syncevolution" (without parameters, for SyncEvolution < 1.3) or "syncevolution --print-databases" (SyncEvolution >= 1.3).

And thats it! - you can now start the process of syncing

Until the radicale bug is fixed (it's already resolved in Radicale's upstream source repository), only use the following:

“syncevolution --sync refresh-from-client radicale” or “syncevolution --sync refresh-from-client radicale calendar2”

to do just one of your calendars


The configuration commands are complex and critical - it is easy to miss-type/get wrong – put them in a small shell script for easy checking.

Make life easy on yourself – name your calendars sensibly. Don't call everything “calendar” as you cant work out what is correct and what isnt. At one point I had “Calendar” (from an exchange server), “calendar” and was using “calendar” as a test configuration – impossible to diagnose :(

Be careful if you cut and paste you do not include any strange characters.

If you make a miss-stake, “rm -rf .config/syncevolution/*” on the n900 and start again – I've found that not doing so didn't always allow consistent results after changes to the configuration. It may be that you will have to manually delete the files from the radicale database as well in extreme cases.

Use a test calendar and take a backup before you start – the ease of miss-typing something and destroying your calendars is high (speaking from experience here! :)

Have you remembered the terminal “/” as indicated above?

Radicale has a good log that in conjunction with “syncevolution loglevel=4 [COMMAND]” which prints to STDOUT in a terminal can provide useful debug. SyncEvolution also keeps per session logs in “.cache/syncevolution”

When a sync fails, SyncEvolution can put a detailed, multimegabyte log in ~.cache/syncevolution – potentially disastrous when the filesystem runs out of space (and you lose your calendars like I did, learn from my mistakes! :)

Radicale is a “simple” server – it doesnt scale well having features like a single file for storage of events including deletes which “collect”. However this simplicity is also its strength and as long as you are aware of this, its fine. However, if the storage reaches around a 1000 entries, radicale and the n900 get very slow, the battery drain on the n900 becomes very noticable and the logs of failed entries can fill the n900 filesystem causing a nasty crash :).
(*Note, potentially risky for the data!) To fix, make sure another client is up to date (I use “lightning”), shut down radicale and delete the files from radicales storage area, delete the radicale log file and restart. When the client reconnects it will create new calendars without any “cruft”. Do a one way resync from radicale to the n900 to restore your calendars.

Have fun!