Ask / Submit
16

OwnCloud CalDAV sync works only after msyncd restart [released]

asked 2017-02-16 02:30:35 +0300

Direc gravatar image

updated 2017-06-23 14:06:26 +0300

Sorry for short and blunt words, I'm very tired and frustrated, but here goes:

So, I am trying to sync my OwnCloud 9.1.4 calendar with my Jolla 2.1.0.9 Iijoki EA (but I bet this has been the case for some updates time...) This is how it goes:

  1. Reboot device
  2. Create CalDAV account on your OwnCloud, disable CarDAV
  3. Credentials are checked et. al.
  4. Choose your calendar of choise and create account
  5. Let it sync
  6. Go to calendar, see that events have synced from cloud to device
  7. Change event on cloud, notice it syncs to device as it shoudl
  8. Change event on device, notice it doesn't sync to cloud, and also all events briefly disappear
  9. Restart msyncd: systemctl --user stop msyncd and systemctl --user start msyncd
  10. Sync calendar manually now for completeness' sake
  11. Change event on device, notice it now syncs to cloud, as it should in the first place

Because restarting msyncd is required in order to enable debug logging, and it also fixes the behavior, it really can't be used... Perhaps this is some on-device race or permission issue?

OwnCloud calendar is fully functional on web browser side, and after the trick it works well on my Jolla, too. That leads into assuming that the server side configuration is just fine.

I have a strong feeling, that this same procedure would fix my similarily functioning Google Calendar, but thanks to two-factor authentication, I can't test it right now.

Jolla, once again, I can provide you a test account if you want to try it out or if you can't reproduce it on your existing installations.

edit retag flag offensive reopen delete

The question has been closed for the following reason "released in a software update" by Direc
close date 2017-06-23 14:06:13.542406

Comments

2

I'll try to reproduce this next week on our test installation in the Mer infrastructure.

In the meantime, could you try to add MSYNCD_LOGGING_LEVEL=8 to the /var/lib/environment/nemo/50-jolla-ui.conf and then rebooting, and seeing if you can get logs as per steps 5+6+7 from https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#Sync_Logs as this doesn't require restarting the msyncd daemon.

Thanks!

chris.adams ( 2017-02-17 08:15:22 +0300 )edit

Thans! I'll try to reproduce it with logging enabled to get the situation logged.

Direc ( 2017-02-17 08:43:42 +0300 )edit

4 Answers

Sort by » oldest newest most voted
5

answered 2017-02-19 11:32:29 +0300

tigerfoot gravatar image

Same problem appear after 2.1.0.9 update against nextcloud 11.0.1 (was working like a charm before) The important part of why it's failing is located on server log. A missing authentifaction

It seems the calendar app is now forgetting to send the authentifaction credentials. The most funny is that Contacts linked to same server is working perfectly.

{"reqId":"ots47E7h9wnghEH3+vcT","remoteAddr":"2a01:2a8:8103:1601:141f:6ca0:27b9:245f","app":"webdav","message":"Exception: {\"Message\":\"HTTP/1.1 401 No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured\",\"Exception\":\"Sabre\DAV\Exception\NotAuthenticated\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\DAV\Auth\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#1 /srv/www/nextcloud/3rdparty/sabre/event/lib/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#2 /srv/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php(466): Sabre\Event\EventEmitter->emit('beforeMethod', Array)\n#3 /srv/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php(254): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#4 /srv/www/nextcloud/apps/dav/lib/Server.php(227): Sabre\DAV\Server->exec()\n#5 /srv/www/nextcloud/apps/dav/appinfo/v2/remote.php(30): OCA\DAV\Server->exec()\n#6 /srv/www/nextcloud/remote.php(165): require_once('/srv/www/nextcl...')\n#7 {main}\",\"File\":\"/srv/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php\",\"Line\":168,\"User\":false}","level":0,"time":"2017-02-19T09:17:17+00:00","method":"REPORT","url":"/remote.php/dav/calendars/**USER.LOGIN**/myagenda/","user":"--","version":"11.0.1.2"}

So it should be normally quite easy to bi-sect calendar and or caldav/carddav application to find what has changed and how to fix it.

A new preview snapshot of 2.1.0 with fixes included would be really appreciate. Don't push 2.1.0 to the wild before that, or expect ton's of angry users ;-)

edit flag offensive delete publish link more

Comments

We don't have NextCloud 11.0.1 in our Mer test server infrastructure, but I tested with Owncloud version 8.1 and Owncloud version 9.0, and cannot reproduce any issue related to missing authorization. (Note that the CalDAV sync adapter can send some requests without authorization, specifically to work around a bug in some CalDAV servers - but then should perform the request with the proper authorization headers set. So, a request lacking proper authorization may well show up in your logs, but should be followed by a properly-authorized request for the same resource, I believe.)

Are you certain that the authorization is causing the sync failure, or is that just a possibility based on the server logs? If the former, can you please provide a complete client-side log (https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#Sync_Logs) so that I can investigate further?

Thanks!

chris.adams ( 2017-02-27 10:17:58 +0300 )edit
4

answered 2017-02-17 21:25:50 +0300

updated 2017-02-17 21:31:17 +0300

Same issue here with an Owncloud 9.1, except that the msyncd restart routine doesn't solve the problem. Before the 2.1.0.9, everything was working great and I did not change a thing in my settings since.

Here is my issue:

  • I go to my calendar, everything is fine, I see all the events that are on my OwnCloud
  • I go create a new event
  • The calendar disappears for a couple of seconds (all the event disappear and the row in "Manage calendars" disappears too)
  • The events are reloaded, but the previously created event cannot be found.

Note that if I create the event on the server directly, it appears in the calendar, only the event creation fails

Here is the log I extracted following the procedure. This log was started at the creation of the event and closed when the calendar reapeared

Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - ProfileManager::syncProfile( "caldav-sync-12" )
Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - found a valid sync profile with the given name: "caldav-sync-12"
Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - ProfileManager::syncProfile( "carddav.Contacts-12" )
Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - found a valid sync profile with the given name: "carddav.Contacts-12"
Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - ProfileManager::syncProfile( "caldav-sync" )
Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - found a valid sync profile with the given name: "caldav-sync"
Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - No sync log found for profile: "caldav-sync"
Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - ProfileManager::syncProfile( "carddav.Contacts" )
Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - found a valid sync profile with the given name: "carddav.Contacts"
Feb 17 20:21:14 Sailfish estart[8108]: [D] unknown:0 - No sync log found for profile: "carddav.Contacts"
Feb 17 20:21:14 Sailfish [1015]: [D] unknown:0 - Start sync requested for profile: "caldav-sync-12"
Feb 17 20:21:14 Sailfish [1015]: [D] unknown:0 - ProfileManager::syncProfile( "caldav-sync-12" )
Feb 17 20:21:14 Sailfish [1015]: [D] unknown:0 - found a valid sync profile with the given name: "caldav-sync-12"
Feb 17 20:21:14 Sailfish [1015]: [D] unknown:0 - Starting sync with profile "caldav-sync-12"
Feb 17 20:21:14 Sailfish [1015]: [D] unknown:0 - Starting oop plugin  "caldav-sync-12"
Feb 17 20:21:14 Sailfish [1015]: [D] unknown:0 - Starting process  "/usr/lib/buteo-plugins-qt5//oopp/caldav-client"  with plugin name  "caldav"  and profile name  "caldav-sync-12"
Feb 17 20:21:14 Sailfish caldav-client[9974]: [W] unknown:0 - This device does not have a BT adapter
Feb 17 20:21:14 Sailfish caldav-client[9974]: [D] unknown:0 - Online status:: true
Feb 17 20:21:14 Sailfish caldav-client[9974]: [D] unknown:0 - attempting to register dbus service: "com.buteo.msyncd.plugin.caldav-sync-12"
Feb 17 20:21:14 Sailfish caldav-client[9974]: [D] unknown:0 - Plugin  "caldav"  with profile  "caldav-sync-12"  registered at dbus  "com.buteo.msyncd.plugin.caldav-sync-12"  and path  /
Feb 17 20:21:15 Sailfish [1015]: [D] unknown:0 - Process  "/usr/lib/buteo-plugins-qt5//oopp/caldav-client"  started with pid  9974
Feb 17 20:21:16 Sailfish [1015]: [D] unknown:0 - ClientPluginRunner started thread for plugin: "caldav-sync-12" , returning: true
Feb 17 20:21:16 Sailfish [1015]: [D] unknown:0 - ProfileManager::syncProfile( "caldav-sync-12" )
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - Primary profile path set to "/home/nemo/.cache/msyncd"
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - Secondary profile path set to "/etc/buteo/profiles"
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - ProfileManager::syncProfile( "caldav-sync-12" )
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - found a valid sync profile with the given name: "caldav-sync-12"
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - lastSync: QDateTime(2017-02-17 19:20:07.000 UTC Qt::TimeSpec(UTC))
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - lastSync: QDateTime(2017-02-17 19:20:07.000 UTC Qt::TimeSpec(UTC))
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - lastSync: QDateTime(2017-02-17 19:20:07.000 UTC Qt::TimeSpec(UTC))
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - lastSync: QDateTime(2017-02-17 19:20:07.000 UTC Qt::TimeSpec(UTC))
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - lastSync: QDateTime(2017-02-17 19:20:07.000 UTC Qt::TimeSpec(UTC))
Feb 17 20:21:16 Sailfish [1015]: [D] unknown:0 - found a valid sync profile with the given name: "caldav-sync-12"
Feb 17 20:21:16 Sailfish [1015]: [D] unknown:0 - ProfileManager::syncProfile( "caldav-sync-12" )
Feb 17 20:21:16 Sailfish [1015]: [D] unknown:0 - found a valid sync profile with the given name: "caldav-sync-12"
Feb 17 20:21:16 Sailfish [1015]: [D] unknown:0 - ProfileManager::syncProfile( "carddav.Contacts-12" )
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - Initiating config...
Feb 17 20:21:16 Sailfish [1015]: [D] unknown:0 - found a valid sync profile with the given name: "carddav.Contacts-12"
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - connection-manager.cpp 106 setupSocketConnection p2p error: QDBusError("org.freedesktop.DBus.Error.FileNotFound", "Failed to connect to socket /run/user/100000/signond/socket: No such file or directory") 1
Feb 17 20:21:16 Sailfish caldav-client[9974]: [D] unknown:0 - connection-manager.cpp 132 init Peer connection unavailable, activating service
Feb 17 20:21:16 Sailfish caldav-client[9974]: [W] unknown:0 - sqlitestorage.cpp: 193 - database "/home/nemo/.local/share/system/privileged/Calendar/mkcal/db" opened
Feb 17 20:21:16 Sailfish caldav-client[9974]: [W] unknown:0 - Deleting caldav notebooks associated with this account: 12 due to clean sync
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:d45b7c0c-802e-4361-82a1-fa17c1bf012e" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:d45b7c0c-802e-4361-82a1-fa17c1bf012e"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:b3574add-bb4b-4291-b3c0-ada8fbfa845f" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:b3574add-bb4b-4291-b3c0-ada8fbfa845f"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:a0a57f21-ec8e-451b-abb8-f441db266ad7" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:a0a57f21-ec8e-451b-abb8-f441db266ad7"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:1a4176f3-5fb2-409b-b096-fd23c7518dc6" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:1a4176f3-5fb2-409b-b096-fd23c7518dc6"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:bd7bd34c-072c-4274-9979-c5b8d2540049" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:bd7bd34c-072c-4274-9979-c5b8d2540049"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:330d82ac-0878-4a98-b9d6-f2813a5321c6" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:330d82ac-0878-4a98-b9d6-f2813a5321c6"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:5a31100e-c4cc-4d5b-b940-62ef2c82e752" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:5a31100e-c4cc-4d5b-b940-62ef2c82e752"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:1c74eec5-c957-4d14-a6d7-644b319d2b49" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:1c74eec5-c957-4d14-a6d7-644b319d2b49"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:0e2042f9-4570-4efa-b9a0-6ad788d2299f" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:0e2042f9-4570-4efa-b9a0-6ad788d2299f"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:823da900-3076-449b-a849-05635c2fab01" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:823da900-3076-449b-a849-05635c2fab01"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:cace9c98-66ed-4ccc-8724-f5d564a427da" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:cace9c98-66ed-4ccc-8724-f5d564a427da"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:7136125c-59bd-4454-965b-a8a58c3ee855" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:7136125c-59bd-4454-965b-a8a58c3ee855"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:67020763-34bd-4486-9054-b269f9161612" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:67020763-34bd-4486-9054-b269f9161612"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:32299021-605f-44d5-a601-cfe6d6ea7b0c" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:32299021-605f-44d5-a601-cfe6d6ea7b0c"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:6m2v20qia4cswbei7kmo3zbyb9" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:6m2v20qia4cswbei7kmo3zbyb9"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:948fbc15-f9ed-433a-bdfb-84b674f122ac" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:948fbc15-f9ed-433a-bdfb-84b674f122ac"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:85b5f583-c972-446d-8514-236d3dc4b2d0" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:85b5f583-c972-446d-8514-236d3dc4b2d0"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:ce72e688-8a2c-4d7d-af96-771b96027266" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:ce72e688-8a2c-4d7d-af96-771b96027266"
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqliteformat.cpp: 178 - failed to select rowid of incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:73b7928a-b0f4-4351-84f5-2bdf6f94c753" ""
Feb 17 20:21:17 Sailfish caldav-client[9974]: [C] unknown:0 - sqlitestorage.cpp: 2069 - not an error for incidence "NBUID:8a88ac39-4c82-4094-a294-edd9c1d5b3d9:73b7928a-b0f4-4351-84f5-2bdf6f94c753"
Feb 17 20:21:18 Sailfish caldav-client[9974]: [W] unknown:0 - Deleting caldav notebooks associated with nonexistent accounts due to clean sync
Feb 17 20:21:18 Sailfish caldav-client[9974]: [W] unknown:0 - Finished pre-sync cleanup with caldav account 12
edit flag offensive delete publish link more

Comments

same here I did nothing changed

poddl ( 2017-02-17 23:20:48 +0300 )edit

Not restricted to owncloud. Same behavior with baïkal 0.4.5 and 0.4.6. Events shows up just fine if created elsewhere.

ljo ( 2017-02-18 01:55:38 +0300 )edit

I have same problem with ownCloud 8.2 sync.

Rulli ( 2017-02-19 16:00:27 +0300 )edit

What's wrong with these Deleting caldav notebooks associated with this account: **** due to clean sync messages? I use baikal 0.4.6 / lighttpd to sync with CalDav. On every sync, all synced calendars are deleted, just to be re-created later on. Really annoying that colors are lost then... This behaviour came with the 2.1.0.9 update. The weird thing: According to the code this 'notebook deletion' happens when in the file /home/nemo/.local/system/privileged/Sync/caldav.ini the corresponding *-cleaned is set to true (which it is always, because in the end of the cleaning it is set to true). But that portion of code was last changed a year ago... I don't get it.

NobodyInPerson ( 2017-02-25 23:53:20 +0300 )edit

@NobodyInPerson actually, the clean sync will occur if the accountId-notebook-cleaned value is false. If that value is true, then no clean sync will occur. So what can trigger this case is if the accountId for the account changes (which should happen only if an account is migrated e.g. for backup-restore purposes).

There is a bug in which it seems that an account migration can occur after a random reboot - see https://bugs.merproject.org/show_bug.cgi?id=1699 - but I haven't yet been able to identify why this occurs. Most likely a oneshot script is being run on every reboot rather than on upgrade-reboot only.

chris.adams ( 2017-02-27 08:32:11 +0300 )edit
4

answered 2017-03-02 12:47:27 +0300

NobodyInPerson gravatar image

updated 2017-03-03 16:50:38 +0300

Note: Consider just installing @chris.adam 's patch rpm file in the comments to this answer (How the hell does one link to comments?). It involves less typing and just works.

Okay, I might have found a workaround to be able to use the calendar again.

The problem seems to be that somehow the sync mechanism doesn't remember the state correctly and thinks every calendar needs to be wiped to have everything clean. That leads to events and calendar colors getting lost. At least for me.

The 'clean' state is saved to /home/nemo/.local/share/system/privileged/Sync/caldav.ini.

For the workaround, first find out your calendar IDs from the database. With developer mode enabled, open the Terminal app and run:

devel-su

and enter your password. Then run

echo "select account,Name,color,syncProfile from Calendars;" | sqlite3 /home/nemo/.local/share/system/privileged/Calendar/mkcal/db

You should see a list, each line beginning with a number. That are the IDs for the calendars.

In the file /home/nemo/.local/share/system/privileged/Sync/caldav.ini, add lines for each of your calendars (except Default and Birthdays, which don't have IDs anyway, I would say) that look like:

92-cleaned=true
93-cleaned=true

Then everything should work as expected. I hope so :-)

Regards,

nobodyinperson

edit flag offensive delete publish link more

Comments

Thanks for your help investigating this issue :-)

chris.adams ( 2017-03-03 10:02:09 +0300 )edit

Great, that worked.

Thanks.

ricardo ( 2017-03-03 10:11:56 +0300 )edit

@chris.adams You're very welcome. I love this OS and adore how open mer is. Being able to browse freely through the source code is just marvellous :-D

NobodyInPerson ( 2017-03-03 10:47:30 +0300 )edit

For me that workaround doesn't work if i'm entering the command to get the Calendar IDs. I'm getting asked for a password. After a very short while without entering anything there comes : Auth failed.

edit: Donwloaded the database to my PC and opened it there with a db-Browser to get the IDs. That worked and now caldav works again.

Anyway, has anyone an idea why that command didn't work on my device?

Fellfrosch ( 2017-03-03 11:14:54 +0300 )edit

@Fellfrosch Everything is fine with the password. It is the password you specified with developer mode ssh access. The calendar database can only be accessed with privileges, thus the password is asked for.

NobodyInPerson ( 2017-03-03 13:29:32 +0300 )edit
0

answered 2017-06-23 14:04:59 +0300

Direc gravatar image

I'm now running SFOS 2.1.0.11 and OwnCloud still at 9.1.4 but I can't reproduce the problem anymore. Release note say "2017-03-23: 2.1.0.10 Early access release for Jolla 1, C and Tablet. Fixes for instance for camera ticking and CalDAV sync issues." so I took the liberty to add this page to the ticket list.

edit flag offensive delete publish link more

Question tools

Follow
13 followers

Stats

Asked: 2017-02-16 02:30:35 +0300

Seen: 943 times

Last updated: Jun 23