Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared calendars not editable via caldav #26667

Closed
romris opened this issue Nov 21, 2016 · 36 comments

Comments

Projects
None yet
@romris
Copy link

commented Nov 21, 2016

Steps to reproduce

  1. Open (via caldav) a calendar that is shared with you and for that you have the permission to make changes
  2. Try to make changes
  3. Synchnonize and see that your changes have no effect

Expected behaviour

Changes should be synchronized.

Actual behaviour

Changes are not synchronized.

Server configuration

Operating system: Ubuntu

Web server: Apache

Database: MySQL

PHP version:

ownCloud version: 9.1.2

@PVince81

This comment has been minimized.

Copy link
Member

commented Nov 22, 2016

@DeepDiver1975 is this a known issue ?

@cgogolin

This comment has been minimized.

Copy link

commented Nov 24, 2016

I think I have the same issue. It started with the update 9.1.1-1.2 -> 9.1.2-1.1.

Since then I can no longer edit or add entries in/to shared calendars via carddav. This happens even though the user has granted me permission to edit and the "can edit" box is also ticked in the owncloud calendar app. I can still create and add entries via the owncloud web interface. I can however no longer edit shared calendars with davdroid and evolution mail.

Davdroid says:

<?xml version="1.0" encoding="utf-8"?>[LF]
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">[LF]
  <s:sabredav-version>3.0.9</s:sabredav-version>[LF]
  <s:exception>Sabre\DAV\Exception\NotFound</s:exception>[LF]
  <s:message>Principal with name users not found</s:message>[LF]
</d:error>[LF]

EXCEPTION:
at.bitfire.dav4android.exception.NotFoundException: 404 Not Found
        at at.bitfire.dav4android.DavResource.checkStatus(DavResource.java:310)
        at at.bitfire.dav4android.DavResource.checkStatus(DavResource.java:291)
        at at.bitfire.dav4android.DavResource.put(DavResource.java:202)
        at at.bitfire.davdroid.syncadapter.SyncManager.uploadDirty(SyncManager.java:317)
        at at.bitfire.davdroid.syncadapter.SyncManager.performSync(SyncManager.java:147)
        at at.bitfire.davdroid.syncadapter.CalendarsSyncAdapterService$SyncAdapter.sync(CalendarsSyncAdapterService.java:68)
        at at.bitfire.davdroid.syncadapter.SyncAdapterService$SyncAdapter.onPerformSync(SyncAdapterService.java:85)
        at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)

Evolution says:

Failed to create an event in the calendar 'CalDAV : Manu_Christian' 
Cannot create calendar object: Object not found
@cgogolin

This comment has been minimized.

Copy link

commented Nov 27, 2016

With newly created calendars everything seems to work. Only those present during the update can not be edited anymore.

What is the best way to find out in which way the newly created calendars differ from the old ones?

@DeepDiver1975 DeepDiver1975 self-assigned this Nov 28, 2016

@DeepDiver1975 DeepDiver1975 added this to the 9.2 milestone Nov 28, 2016

@DeepDiver1975

This comment has been minimized.

Copy link
Member

commented Nov 28, 2016

What is the best way to find out in which way the newly created calendars differ from the old ones?

Please have a look in the database - let's start with:

select * from oc_calendars

@cgogolin

This comment has been minimized.

Copy link

commented Nov 28, 2016

I have uploaded the output of that command (shortened to only include the relevant users). The (newly created) shared calendar that works is Christian_Manu shared from cgogolin to manuela.mergel. The one that doesn't work (but worked before the upgrade) is Manu_Christian shared from manuela.mergel to cgogolin.

@DeepDiver1975

This comment has been minimized.

Copy link
Member

commented Nov 28, 2016

thx - can I ask you to the table contents of the oc_dav_shares table?

select * from oc_dav_shares where resourceid = 9;
select * from oc_dav_shares where resourceid = 23;

@cgogolin

This comment has been minimized.

Copy link

commented Nov 28, 2016

Here is the output:

mysql> select * from oc_dav_shares where resourceid = 9;
+----+---------------------------+----------+--------+------------+
| id | principaluri              | type     | access | resourceid |
+----+---------------------------+----------+--------+------------+
|  7 | principals/users/cgogolin | calendar |      2 |          9 |
+----+---------------------------+----------+--------+------------+
1 row in set (0.00 sec)

mysql> select * from oc_dav_shares where resourceid = 23;
+----+---------------------------------+----------+--------+------------+
| id | principaluri                    | type     | access | resourceid |
+----+---------------------------------+----------+--------+------------+
|  9 | principals/users/manuela.mergel | calendar |      2 |         23 |
+----+---------------------------------+----------+--------+------------+
1 row in set (0.00 sec)
@DeepDiver1975

This comment has been minimized.

Copy link
Member

commented Nov 28, 2016

hmmm ... nothing strange .....

@raoulbhatia

This comment has been minimized.

Copy link

commented Nov 29, 2016

I am affected as well.

@cgogolin

This comment has been minimized.

Copy link

commented Dec 4, 2016

To work around the problem I decided yesterday to copy over all entries from the dysfunctional calendar to the newly created one (export to .ics, then import, both with Evolution) and simply use the new calendar instead of the old one.

Unfortunately, after copying over all events, the new calendar now shows the same behavior as the old one. The person sharing the calendar can still create/edit/delete events normally, the person to which the calendar is shared can not do any of those anymore.

The errors shown by Evolution and Davdroid are the same as above.

I suspect that there is a problem with some of the calendar entries. How can I help out wich ones cause the problem? The number of entries is much too large to analyse them manually. Is there anything I could look for? Special characters or something?

@cgogolin

This comment has been minimized.

Copy link

commented Dec 4, 2016

Digging a little deeper reveals a another level of absurdity of this problem: Thunderbird with SOGo Connector 24.0.6 is able to write to the shared calendars using the account to which they were shared, but not, as explained above, Evolution mail or Davdroid.

@cgogolin

This comment has been minimized.

Copy link

commented Dec 4, 2016

I think this is a server issue, but have also opened a bug report with Davdroid to geht their opinion. You can see the full debug output of Davdroid here.

@cgogolin

This comment has been minimized.

Copy link

commented Dec 4, 2016

Another piece of potentially useful information (sorry for bringing them up one by one, I am not experienced with debugging ownclound): I get this error message repeaded many times in owncloud.log

{"reqId":"rDG6xl4h4Wp+ZxdzTeXa","remoteAddr":"90.170.253.225","app":"caldav","message":"Exception: {\"Message\":\"This recurrence rule does not generate any valid instances\",\"Exception\":\"Sabre\\\\VObject\\\\Recur\\\\NoInstancesException\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/CalDAV\\\/CalDavBackend.php(1352): Sabre\\\\VObject\\\\Recur\\\\EventIterator->__construct(Object(Sabre\\\\VObject\\\\Component\\\\VCalendar), 'oirerhq5m394857...')\\n#1 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/CalDAV\\\/CalDavBackend.php(658): OCA\\\\DAV\\\\CalDAV\\\\CalDavBackend->getDenormalizedData('BEGIN:VCALENDAR...')\\n#2 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/CalDAV\\\/CalendarObject.php(104): OCA\\\\DAV\\\\CalDAV\\\\CalDavBackend->updateCalendarObject('8', 'oirerhq5m394857...', 'BEGIN:VCALENDAR...')\\n#3 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(1070): Sabre\\\\CalDAV\\\\CalendarObject->put('BEGIN:VCALENDAR...')\\n#4 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(511): Sabre\\\\DAV\\\\Server->updateFile('calendars\\\/manue...', Resource id #75, NULL)\\n#5 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpPut(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#6 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#7 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(459): Sabre\\\\Event\\\\EventEmitter->emit('method:PUT', Array)\\n#8 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(248): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#9 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/caldav.php(83): Sabre\\\\DAV\\\\Server->exec()\\n#10 \\\/var\\\/www\\\/owncloud\\\/remote.php(164): require_once('\\\/var\\\/www\\\/ownclo...')\\n#11 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/vobject\\\/lib\\\/Recur\\\/EventIterator.php\",\"Line\":199,\"User\":\"manuela.mergel\"}","level":4,"time":"2016-12-03T18:19:52+00:00","method":"PUT","url":"\/owncloud\/remote.php\/caldav\/calendars\/manuela.mergel\/personal\/oirerhq5m394857stp7fti1j24%2540google.com.ics","user":"manuela.mergel"}

To me it looks as if that is what the server is saying when the client fails to edit the shared calendar.

@daniell1

This comment has been minimized.

Copy link

commented Dec 20, 2016

I'm affected as well. I can confirm that this happens since version 9.1.2. Upgrading to 9.1.3 didn't fix it. The clients I'm using are Thunderbird 45.5.1 with Lightning 4.7.5.1 and DAVdroid 1.3.4.1. My server is running on Fedora with ownCloud shipped by Fedora. I already reported the issue there for documentation: https://bugzilla.redhat.com/show_bug.cgi?id=1405715

PS: Editing shared calendars via WebGUI is working.

@cgogolin

This comment has been minimized.

Copy link

commented Dec 20, 2016

I have one additional piece of information: Between users created after the update sharing of calendars seems to work normally.

@Bilemma

This comment has been minimized.

Copy link

commented Dec 28, 2016

I had the same problem - by now I did not update to owncloud 9.1.3.
I use DAVdroid 1.3.4.1 for syncing to android.

What worked for me today was changing the account details in DAVdroid to:

CalDAV/CardDAV path: /remote.php/dav/ (e.g. https://server.example/owncloud/remote.php/dav/)

(Found here: https://davdroid.bitfire.at/configuration/owncloud/ )

I don't understand why this helps, but it does for me. I keep you updated, if further errors occur later.

@daniell1

This comment has been minimized.

Copy link

commented Dec 29, 2016

Hi. Thanks for sharing this with us. It solves the problem in Thunderbird Lightning as well.

PS: The sharing URL in the WebGui is correct too.

@simogeo

This comment has been minimized.

Copy link

commented Jan 5, 2017

Same problem here after 9.1.3 upgrade ....

Here is the output of select * from oc_dav_shares :

image

Just wondering if access value '3' is correct or not .....

and I can see the following log :

Exception: {"Message":"HTTP/1.1 404 Node with name 'commun-intermezzo_shared_by_simon' could not be found","Exception":"Sabre\DAV\Exception\NotFound","Code":0,"Trace":"#0 /var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php(796): OCA\DAV\Connector\Sabre\DavAclPlugin->checkPrivileges('calendars/laure...', '{DAV:}bind')\n#1 [internal function]: Sabre\DAVACL\Plugin->beforeBind('calendars/laure...')\n#2 /var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#3 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php(1021): Sabre\Event\EventEmitter->emit('beforeBind', Array)\n#4 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php(523): Sabre\DAV\Server->createFile('calendars/laure...', Resource id #64, NULL)\n#5 [internal function]: Sabre\DAV\CorePlugin->httpPut(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#6 /var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#7 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php(459): Sabre\Event\EventEmitter->emit('method:PUT', Array)\n#8 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#9 /var/www/owncloud/apps/dav/appinfo/v1/caldav.php(83): Sabre\DAV\Server->exec()\n#10 /var/www/owncloud/remote.php(164): require_once('/var/www/ownclo...')\n#11 {main}","File":"/var/www/owncloud/apps/dav/lib/Connector/Sabre/DavAclPlugin.php","Line":62,"User":"laurent"}

Thanks for your help

@daniell1

This comment has been minimized.

Copy link

commented Jan 5, 2017

With which URL are you accessing the calendars? Are you accessing them like Bilemma described three posts above? I'm on 9.1.3 as well and it helped.

@simogeo

This comment has been minimized.

Copy link

commented Jan 5, 2017

I've tried replacing the full url by https://server.example/owncloud/remote.php/dav/

I also tried the proposed fix here : https://doc.owncloud.org/server/9.0/admin_manual/issues/general_troubleshooting.html#service-discovery-label

settings url as 'https://server.example/' and adding 'Redirect 301 /.well-known/caldav /owncloud/remote.php/dav' to .htaccess with no success ....

any clue ?

@hessijames79

This comment has been minimized.

Copy link

commented Jan 25, 2017

Same problem here with Owncloud 9.1.3 and URL http://$host/owncloud/remote.php/dav/ (as well as the old caldav ones...)

@simogeo

This comment has been minimized.

Copy link

commented Jan 27, 2017

someone, any news regarding this bug ? any fix to provide ?

@raoulbhatia

This comment has been minimized.

Copy link

commented Jan 27, 2017

I suppose the only resolution is updating to Nextcloud?
See nextcloud/server#2402 Comment #263572190

@simogeo

This comment has been minimized.

Copy link

commented Jan 27, 2017

And, is there somewhere a migration howto ?

@raoulbhatia

This comment has been minimized.

Copy link

commented Jan 27, 2017

@simogeo

This comment has been minimized.

Copy link

commented Jan 27, 2017

Thanks for this. Does owncloud client still works with nextcloud server ?

@hessijames79

This comment has been minimized.

Copy link

commented Jan 28, 2017

I managed to get it solved on my system.

I am using the Debian package of Owncloud without any modifications. Hence, owncloud is located at http://HOST/owncloud. I added the following lines to the VirtualHost in /etc/apache2/sites-available/000-default:
Redirect 301 /.well-known/carddav /owncloud/remote.php/dav
Redirect 301 /.well-known/caldav /owncloud/remote.php/dav
After restarting Apache, adding events to a shared calendar worked.

@raoulbhatia

This comment has been minimized.

Copy link

commented Jan 28, 2017

@simogeo Please do a little research by yourself.
There is extensive documentation available via your favorite search engine.

Thanks,
Raoul

@sumnerboy12

This comment has been minimized.

Copy link

commented Jan 28, 2017

I am seeing this too (on v9.1.3) and noticed this in my Apache2 logs;

When creating an event using the calendar owner (me) it works fine;

192.168.10.1 - ben [29/Jan/2017:09:16:47 +1300] "PUT /owncloud/remote.php/caldav/calendars/ben/family/987f8453-9bcb-4e4a-b41e-83f6c3157426.1485634607487.ics HTTP/1.1" 201 1129 "-" "CalDAV-Sync/0.4.27 (samsung; heroltexx; Android 6.0.1; en_NZ; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"

But when doing the same thing for a shared calendar (i.e. same calendar but different user via a share);

192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/a5205fc6-0453-47f8-bcc1-01baa329f662.1485634432282.ics HTTP/1.1" 404 1398 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/bd15e605-8c20-4c47-b9c5-ee1a987a83c6.1485634432447.ics HTTP/1.1" 404 1400 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/52a39568-8db9-495b-9cb1-c26acdbdb5d2.1485634432617.ics HTTP/1.1" 404 1396 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/1d50fc43-4335-4abd-a1a9-479faec1a590.1485634432764.ics HTTP/1.1" 404 1402 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/d8c513e1-9f15-4466-bbba-f1b474fa3b41.1485634432916.ics HTTP/1.1" 404 1406 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:57 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/3c9d170d-539f-4c16-bdc8-6ae2c6cb756c.1485634433074.ics HTTP/1.1" 404 1394 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
192.168.10.1 - renee [29/Jan/2017:09:13:58 +1300] "PUT /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/8cb18519-9354-474a-b4a9-345d6379ec09.1485634433268.ics HTTP/1.1" 404 1396 "-" "CalDAV-Sync/0.4.27 (HTC; optus_au; Android 5.0.2; en_AU; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"

I am no expert but wondered if this might help the developers looking at this?

Looks like the request to create the event is getting a 404 for the shared URL (i.e. /owncloud/remote.php/caldav/calendars/renee/family_shared_by_ben/) but works fine for direct (non-shared) access (/owncloud/remote.php/caldav/calendars/ben/family/).

Would love to get this working as currently anything my wife adds to the family calendar is not synchronised and thus no one else knows about!!

@daniell1

This comment has been minimized.

Copy link

commented Jan 28, 2017

Seems like you are not using the correct URLs. Have you either configured your clients as described here #26667 (comment) or your server as described in the troubleshooting guide that was linked in this comment #26667 (comment) ?

@sumnerboy12

This comment has been minimized.

Copy link

commented Jan 29, 2017

Thanks guys - I had provisioned my Android phones using CALDav-Sync and entering <servername>/owncloud as the URL. It then found the caldav URL and I could see/edit my own calendars, so just thought it was ok. But this meant shared calendars couldn't be edited. By explicitly entering <servername>/owncloud/remote.php/dav everything seems to be working now. Thanks again!

@raoulbhatia

This comment has been minimized.

Copy link

commented Jan 30, 2017

After some additional debugging, I also figured out that the issue lies within the URL configuration, i.e.

  • Old: /remote.php/caldav/[...]
  • New: /remote.php/dav/[...]

I have no idea why there is a difference between direct and shared calendars.
Nevertheless, I've also completed my transition to Nextcloud this weekend.

Last but not least, I think that one would be able to create a (temporary) workaround by using the rewrite capabilities of the webserver.
I.e. for nginx; incomplete & not fully tested:

rewrite ^/?.well-known/carddav /remote.php/dav permanent;
rewrite ^/?.well-known/caldav /remote.php/dav permanent;

rewrite ^/remote.php/carddav/addressbooks(.*) /remote.php/dav/addressbooks/users$1 permanent;
[...]
@simogeo

This comment has been minimized.

Copy link

commented Jan 30, 2017

I'll also switch to nextcloud ... thanks

@jens-maus

This comment has been minimized.

Copy link

commented Mar 28, 2017

After upgrading to 9.1.x I was suffering from the exact same problem as documented here. To solve my issues with not being able to edit/delete shared calendar entries I added the following workaround to my nginx config:

# workaround for bug in 9.1.x
rewrite ^/.well-known/carddav /remote.php/dav/ permanent;
rewrite ^/.well-known/caldav /remote.php/dav/ permanent;
rewrite ^/remote.php/caldav/calendars/(.*) /remote.php/dav/calendars/$1 permanent;

This immediately solved my issues and I am able to edit shared calendar entries again. However, if this issue is really already solved in nextcloud but not on owncloud I really have to evaluate to switch to NextCloud soon.

@nobswolf

This comment has been minimized.

Copy link

commented Apr 11, 2017

same issue in 8.2.9 , BTW

edit: not exactly the same as it seems: even in a new non-shared calendar it does not work

@DeepDiver1975

This comment has been minimized.

Copy link
Member

commented May 17, 2017

This was fixed with 10.0.1 - see #27792

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.