Calendars and contacts should still be there and accessible through the web interface as well as the existing WebDAV endpoints
"PROPFIND /remote.php/carddav/addressbooks/284db192-041e-1029-8d1e-87d3446ede58/ HTTP/1.1" 404 289
"PROPFIND /remote.php/caldav/calendars/284db192-041e-1029-8d1e-87d3446ede58/ HTTP/1.1" 404 289
"PROPFIND /remote.php/dav/principals/users/_my_login_/ HTTP/1.1" 404 240
Operating system: CentOS 7.2
Web server: Apache 2.4.6
Database: MariaDB 5.5.44
PHP version: 5.4.16
ownCloud version: (see ownCloud admin page) 9.0.0
Updated from an older ownCloud or fresh install: Updated from 8.2.2
Where did you install ownCloud from: RPM from the official ownCloud yum repo
Signing status (ownCloud 9.0 and above): All clear
List of activated apps:
Enabled:
- calendar: 1.0
- comments: 0.2
- contacts: 1.0.0.0
- dav: 0.1.5
- encryption: 1.2.0
- federatedfilesharing: 0.1.0
- federation: 0.0.4
- files: 1.4.4
- files_pdfviewer: 0.8
- files_sharing: 0.9.1
- files_texteditor: 2.1
- files_versions: 1.2.0
- files_videoplayer: 0.9.8
- firstrunwizard: 1.1
- gallery: 14.5.0
- notifications: 0.2.3
- provisioning_api: 0.4.1
- systemtags: 0.2
- templateeditor: 0.1
- updatenotification: 0.1.0
- user_ldap: 0.8.0
Disabled:
- activity
- external
- files_external
- files_trashbin
- user_external
The content of config/config.php:
{
"system": {
"instanceid": "XXX",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"datadirectory": "\/var\/owncloud",
"dbtype": "mysql",
"version": "9.0.0.19",
"dbname": "owncloud",
"dbhost": "localhost",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"forcessl": true,
"theme": "",
"maintenance": false,
"loglevel": "2",
"log_rotate_size": 52428800,
"trusted_domains": [
"XXX"
],
"mail_smtpmode": "smtp",
"mail_from_address": "XXX",
"mail_domain": "XXX",
"mail_smtphost": "localhost",
"mail_smtpport": "25",
"ldapIgnoreNamingRules": false,
"secret": "***REMOVED SENSITIVE VALUE***",
"singleuser": false,
"appstore.experimental.enabled": false,
"updatechecker": false
}
}
Are you using external storage, if yes which one: no
Are you using encryption: yes
Are you using an external user-backend, if yes which one: LDAP
+-------------------------------+------------------------------------------------+
| Configuration | |
+-------------------------------+------------------------------------------------+
| hasMemberOfFilterSupport | 0 |
| hasPagedResultSupport | |
| homeFolderNamingRule | |
| lastJpegPhotoLookup | 0 |
| ldapAgentName | |
| ldapAgentPassword | *** |
| ldapAttributesForGroupSearch | |
| ldapAttributesForUserSearch | |
| ldapBackupHost | |
| ldapBackupPort | |
| ldapBase | ou=xxx,dc=xxx,dc=xxx |
| ldapBaseGroups | dc=xxx,dc=xxx |
| ldapBaseUsers | ou=xxx,dc=xxx,dc=xxx |
| ldapCacheTTL | 600 |
| ldapConfigurationActive | 1 |
| ldapDynamicGroupMemberURL | |
| ldapEmailAttribute | mail |
| ldapExperiencedAdmin | 0 |
| ldapExpertUUIDGroupAttr | |
| ldapExpertUUIDUserAttr | |
| ldapExpertUsernameAttr | |
| ldapGroupDisplayName | cn |
| ldapGroupFilter | (&(|(objectclass=top))) |
| ldapGroupFilterGroups | |
| ldapGroupFilterMode | 0 |
| ldapGroupFilterObjectclass | |
| ldapGroupMemberAssocAttr | uniqueMember |
| ldapHost | 127.0.0.1 |
| ldapIgnoreNamingRules | |
| ldapLoginFilter | (&(|(objectclass=xxx))(cn=%uid)) |
| ldapLoginFilterAttributes | |
| ldapLoginFilterEmail | 0 |
| ldapLoginFilterMode | 0 |
| ldapLoginFilterUsername | 1 |
| ldapNestedGroups | 0 |
| ldapOverrideMainServer | |
| ldapPagingSize | 500 |
| ldapPort | 389 |
| ldapQuotaAttribute | |
| ldapQuotaDefault | |
| ldapTLS | 0 |
| ldapUserDisplayName | displayname |
| ldapUserDisplayName2 | |
| ldapUserFilter | (|(objectclass=xxx)) |
| ldapUserFilterGroups | |
| ldapUserFilterMode | 0 |
| ldapUserFilterObjectclass | xxx |
| ldapUuidGroupAttribute | auto |
| ldapUuidUserAttribute | auto |
| turnOffCertCheck | 0 |
| useMemberOfToDetectMembership | 0 |
+-------------------------------+------------------------------------------------+
Browser: Chromium 49.0.2623.75, Chrome 47.0.2526.80
Operating system: OS X 10.11.3
Insert your webserver log here
{"reqId":"Vt-h5mSSkYFxuIM0F0TurgAAAAU","remoteAddr":"xxx","app":"PHP","message":"ldap_search(): 396 is not a valid ldap link resource at \/var\/www\/html\/owncloud\/apps\/user_ldap\/lib\/ldap.php#264","level":3,"time":"2016-03-09T08:42:14+00:00"}
{"reqId":"Vt-h5mSSkYFxuIM0F0TurgAAAAU","remoteAddr":"xxx","app":"PHP","message":"ldap_errno(): 396 is not a valid ldap link resource at \/var\/www\/html\/owncloud\/apps\/user_ldap\/lib\/ldap.php#264","level":3,"time":"2016-03-09T08:42:14+00:00"}
{"reqId":"Vt-h5mSSkYFxuIM0F0TurgAAAAU","remoteAddr":"xxx","app":"PHP","message":"ldap_error(): 396 is not a valid ldap link resource at \/var\/www\/html\/owncloud\/apps\/user_ldap\/lib\/ldap.php#264","level":3,"time":"2016-03-09T08:42:14+00:00"}
{"reqId":"Vt-h5mSSkYFxuIM0F0TurgAAAAU","remoteAddr":"xxx","app":"PHP","message":"ldap_errno(): 396 is not a valid ldap link resource at \/var\/www\/html\/owncloud\/apps\/user_ldap\/lib\/ldap.php#264","level":3,"time":"2016-03-09T08:42:14+00:00"}
{"reqId":"Vt-h5mSSkYFxuIM0F0TurgAAAAU","remoteAddr":"xxx","app":"user_ldap","message":"Error when searching: code ","level":3,"time":"2016-03-09T08:42:14+00:00"}
{"reqId":"Vt-h5mSSkYFxuIM0F0TurgAAAAU","remoteAddr":"xxx","app":"user_ldap","message":"Attempt for Paging? ","level":3,"time":"2016-03-09T08:42:14+00:00"}
Insert your browser log here, this could for example include:
a) The javascript console log
b) The network log
c) ...
cc @DeepDiver1975
Updated with user_ldap-related log entries that I see whenever I attempt to contact the server through CalDAV which results in a 404 from Apache. This could be a clue about incompatibilities related to the user_ldap module.
P.S.: The LDAP configurations dialog in the admin web interface show no errors when testing the configuration, btw. Obviously, there was no problem before doing the upgrade.
P.P.S.: The standard ownCloud Files functionality (e.g. using the ownCloud client software) or logging into the web interface is not affected for users stored in LDAP. All that still works as expected.
CC @blizzz for the LDAP part
@PVince81 old endpoints don't for me either with local users. Needed to switch to /remote.php/dav/
The old endpoints do work me on Android
For me the old and the new endpoints do not work.
I have tested with Android (DAVDroid) and Thunderbird (Linux).
DAVDroid can't find any calendars or address books.
Thunderbird only shows a little yellow warning sign.
The old endpoints also do not work, tested with DAVDroid.
For me, remote.php/dav/calendars/USERNAME/CALENDAR_NAME works. However, in the upgrade process my old calendars (and contacts) somehow got lost. I think this is a major issue and should be fixed as quickly as possible.
I think, however, that this is an issue of the rewrite of the calendar and contacts apps.
Try this:
% curl -u $ocusername -X PROPFIND https://$ochost/remote.php/dav/calendars/$ocusername/
It should show you a list of calendars.
Then you can redo the same by adding the calendar name to the URL, in my case:
% curl -u $ocusername -X PROPFIND https://$ochost/remote.php/dav/calendars/$ocusername/perso
However, in the upgrade process my old calendars (and contacts) somehow got lost.
This isn't enough information to be able to fix it. Was there anything in the logs during the update ?
When I enter the full new endpoint https://my.server/remote.php/dav/ into BusyCal I get the following Apache log entries:
x.x.x.x - [email protected] [09/Mar/2016:09:56:40 +0000] "PROPFIND /remote.php/dav/ HTTP/1.1" 207 1090
x.x.x.x - [email protected] [09/Mar/2016:09:56:40 +0000] "REPORT /remote.php/dav/principals/ HTTP/1.1" 200 768
and that's it. The owncloud.log has the entries reported in the issue description.
@PVince81 The manual curl invocation yields the same results as in my previous comment. The calendars are still there, though, they do show up in the web interface.
@dataflake The web interface is from the calendar GUI app: https://github.com/owncloud/calendar
It already uses Caldav, so not sure why it wouldn't aknowledge the calendar's existence.
So far it is not clear whether it's a bug in the Caldav interface, the way the GUI does the request or something in the data isn't right.
Does the calendar app work correctly for non-LDAP users ? Try creating a new user and setting up calendars. Then do the same with a new LDAP user, setup new calendars.
If that works, then the problem is the migration of old calendars.
@dataflake was the calendar updated? should be 1.0 for OC 9, iirc.
@PVince81 curl command does not work for me aka does not show my calendars.
If i try to connect to one calendar directly I get an error: does not exist.
Strange thing is: I can see my calendars in the web interface - I also created a new one for testing but i can't sync them.
All tested with an non-LDAP user.
@Grot4x open the browser's network console and see what PROPFIND calls are made.
Often the calendar name in caldav is not the same as the display name, you probably used the wrong name. (I have a calendar called "test" internally but display name is "Main")
Also for those where the old endpoints don't work any more, try this:
MariaDB [owncloud]> select * from oc_appconfig where appid='core' and configkey like 'remote_cal%';
+-------+-----------------+---------------------------+
| appid | configkey | configvalue |
+-------+-----------------+---------------------------+
| core | remote_caldav | dav/appinfo/v1/caldav.php |
| core | remote_calendar | dav/appinfo/v1/caldav.php |
+-------+-----------------+---------------------------+
I think we get closer: I created a new user with a new calendar and it works!
My old accounts+calendars still do not work.
So seems like migration is the problem.
@PVince81 I did that but even when i use a url out of the console it says: Node with name '$name' could not be found.
@Grot4x full log for errors please
If it's the migration, the question is "regular user" or "LDAP user" ?
And then, maybe the old calendar data contained fields/value that made the migrator trip over. So need to find out what these values are.
Best would be to check the owncloud.log at the time of the update, whether warnings or exceptions were logged during update.
All my users are regular users. I will check owncloud log for errors with migration
If it's the migration, the question is "regular user" or "LDAP user" ?
Have the same, local users.
Best would be to check the owncloud.log at the time of the update, whether warnings or exceptions were logged during update.
One:
{"reqId":"ig\/h7I1CuOJIvQGMa4H3","remoteAddr":"","app":"dav","message":"One event could not be migrated. (id: 181, calendarid: ): {\"Exception\":\"Doctrine\DBAL\Exception\UniqueConstraintViolationException\",\"Message\":\"An exception occurred while executing 'INSERT INTO `calendarobjects` (`calendarid`, `uri`, `calendardata`, `lastmodified`, `etag`, `size`, `componenttype`, `firstoccurence`, `lastoccurence`, `uid`) VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' with params [3, \"040000008200E00074C5B7101A82E0080000000060F5535C954FCD010000000000000000100000006053F6A5B0777B4F940C\", \"BEGIN:VCALENDAR\r\
PRODID:-\\/\\/Mozilla.org\\/NONSGML Mozilla Calendar V1.1\\/\\/EN\r\
VERSION:2.0\r\
BEGIN:VTIMEZONE\r\
TZID:Eastern Standard Time\r\
BEGIN:STANDARD\r\
DTSTART:16011104T020000\r\
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11\r\
TZOFFSETFROM:-0400\r\
TZOFFSETTO:-0500\r\
END:STANDARD\r\
BEGIN:DAYLIGHT\r\
DTSTART:16010311T020000\r\
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3\r\
TZOFFSETFROM:-0500\r\
TZOFFSETTO:-0400\r\
END:DAYLIGHT\r\
END:VTIMEZONE\r\
BEGIN:VEVENT\r\
CREATED:20120621T140518Z\r\
LAST-MODIFIED:20120621T160054Z\r\
DTSTAMP:20120621T160054Z\r\
UID:040000008200E00074C5B7101A82E0080000000060F5535C954FCD0100000000000000\r\
00100000006053F6A5B0777B4F940CA6B128BEC75C\r\
SUMMARY:ownCloud AD Integration\r\
PRIORITY:5\r\
ORGANIZER;CN=Foobar:mailto:[email protected]\r\
ATTENDEE;RSVP=TRUE;[email protected]:mailto:[email protected]\r\
ATTENDEE;RSVP=TRUE;CN=Foo (Blizzz) ([email protected]);PARTST\r\
AT=ACCEPTED:mailto:[email protected]\r\
DTSTART;TZID=Eastern Standard Time:20120626T120000\r\
DTEND;TZID=Eastern Standard Time:20120626T130000\r\
CLASS:PUBLIC\r\
DESCRIPTION:\\
\r\
LOCATION:+1 559 123 4567\\; PC 987654\\; Germany: +49 (0) 123 456 7890\r\
SEQUENCE:0\r\
TRANSP:OPAQUE\r\
X-ALT-DESC;FMTTYPE=text\\/html:<!DOCTYPE HTML PUBLIC \\"-\\/\\/W3C\\/\\/DTD HTML 3.2\\/\\/\r\
EN\\">\\
<HTML>\\
<HEAD>\\
<META NAME=\\"Generator\\" CONTENT=\\"MS Exchange Server v\r\
ersion 14.02.5004.000\\">\\
<TITLE><\\/TITLE>\\
<\\/HEAD>\\
<BODY>\\
<!-- Converted \r\
from text\\/rtf format -->\\
\\
<P DIR=LTR><SPAN LANG=\\"en-us\\"><\\/SPAN><\\/P>\\
\\
<\r\
\\/BODY>\\
<\\/HTML>\r\
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE\r\
X-MICROSOFT-CDO-IMPORTANCE:1\r\
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY\r\
X-MICROSOFT-DISALLOW-COUNTER:FALSE\r\
X-MS-OLK-AUTOSTARTCHECK:FALSE\r\
X-MS-OLK-CONFTYPE:0\r\
X-MOZ-RECEIVED-SEQUENCE:0\r\
X-MOZ-RECEIVED-DTSTAMP:20120621T140518Z\r\
END:VEVENT\r\
END:VCALENDAR\r\
\", 1457482338, \"996e0329745b941d7986039d25f3ce0f\", 1756, \"VEVENT\", 1340726400, 1340730000, \"040000008200E00074C5B7101A82E0080000000060F5535C954FCD010000000000000000100000006053F6A5B0777B4F940CA6B128BEC75C\"]:\
\
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '3-040000008200E00074C5B7101A82E0080000000060F5535C954FCD01000000' for key 'calobjects_index'\",\"Code\":0,\"Trace\":\"#0 \/var\/www\/minion\/ovin-9.0.0\/3rdparty\/doctrine\/dbal\/lib\/Doctrine\/DBAL\/DBALException.php(116): Doctrine\DBAL\Driver\AbstractMySQLDriver->convertException('An exception oc...', Object(Doctrine\DBAL\Driver\PDOException))\
#1 \/var\/www\/minion\/ovin-9.0.0\/3rdparty\/doctrine\/dbal\/lib\/Doctrine\/DBAL\/Connection.php(996): Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Driver\PDOException), 'INSERT INTO `ca...', Array)\
#2 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/db\/connection.php(205): Doctrine\DBAL\Connection->executeUpdate('INSERT INTO `ca...', Array, Array)\
#3 \/var\/www\/minion\/ovin-9.0.0\/3rdparty\/doctrine\/dbal\/lib\/Doctrine\/DBAL\/Query\/QueryBuilder.php(208): OC\DB\Connection->executeUpdate('INSERT INTO `*P...', Array, Array)\
#4 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/db\/querybuilder\/querybuilder.php(141): Doctrine\DBAL\Query\QueryBuilder->execute()\
#5 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/lib\/caldav\/caldavbackend.php(619): OC\DB\QueryBuilder\QueryBuilder->execute()\
#6 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/lib\/migration\/migratecalendars.php(94): OCA\DAV\CalDAV\CalDavBackend->createCalendarObject(3, '040000008200E00...', 'BEGIN:VCALENDAR...')\
#7 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/lib\/migration\/calendaradapter.php(83): OCA\Dav\Migration\MigrateCalendars->OCA\Dav\Migration\{closure}(Array)\
#8 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/lib\/migration\/migratecalendars.php(104): OCA\Dav\Migration\CalendarAdapter->foreachCalendarObject('6', Object(Closure))\
#9 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/lib\/migration\/migratecalendars.php(78): OCA\Dav\Migration\MigrateCalendars->migrateCalendar('6', 3)\
#10 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/lib\/migration\/calendaradapter.php(62): OCA\Dav\Migration\MigrateCalendars->OCA\Dav\Migration\{closure}(Array)\
#11 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/lib\/migration\/migratecalendars.php(80): OCA\Dav\Migration\CalendarAdapter->foreachCalendar('arthur', Object(Closure))\
#12 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/appinfo\/application.php(207): OCA\Dav\Migration\MigrateCalendars->migrateForUser('arthur')\
#13 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/user\/manager.php(339): OCA\Dav\AppInfo\Application->OCA\Dav\AppInfo\{closure}(Object(OC\User\User))\
#14 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/appinfo\/application.php(208): OC\User\Manager->callForAllUsers(Object(Closure))\
#15 \/var\/www\/minion\/ovin-9.0.0\/apps\/dav\/appinfo\/install.php(27): OCA\Dav\AppInfo\Application->migrateCalendars()\
#16 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/installer.php(621): include('\/var\/www\/minion...')\
#17 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/installer.php(572): OC_Installer::includeAppScript('\/var\/www\/minion...')\
#18 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/installer.php(546): OC_Installer::installShippedApp('dav')\
#19 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/updater.php(336): OC_Installer::installShippedApps()\
#20 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/updater.php(215): OC\Updater->doUpgrade('9.0.0.19', '8.2.3.2')\
#21 \/var\/www\/minion\/ovin-9.0.0\/core\/command\/upgrade.php(225): OC\Updater->upgrade()\
#22 \/var\/www\/minion\/ovin-9.0.0\/3rdparty\/symfony\/console\/Command\/Command.php(259): OC\Core\Command\Upgrade->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))\
#23 \/var\/www\/minion\/ovin-9.0.0\/3rdparty\/symfony\/console\/Application.php(840): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))\
#24 \/var\/www\/minion\/ovin-9.0.0\/3rdparty\/symfony\/console\/Application.php(192): Symfony\Component\Console\Application->doRunCommand(Object(OC\Core\Command\Upgrade), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))\
#25 \/var\/www\/minion\/ovin-9.0.0\/3rdparty\/symfony\/console\/Application.php(123): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))\
#26 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/console\/application.php(145): Symfony\Component\Console\Application->run(NULL, NULL)\
#27 \/var\/www\/minion\/ovin-9.0.0\/console.php(88): OC\Console\Application->run()\
#28 \/var\/www\/minion\/ovin-9.0.0\/occ(11): require_once('\/var\/www\/minion...')\
#29 {main}\",\"File\":\"\/var\/www\/minion\/ovin-9.0.0\/3rdparty\/doctrine\/dbal\/lib\/Doctrine\/DBAL\/Driver\/AbstractMySQLDriver.php\",\"Line\":66}","level":3,"time":"2016-03-09T00:12:18+00:00","method":"--","url":"--"}
I applied https://github.com/owncloud/core/pull/23008 (refering to something different) and suddenly sync worked for my wife again with. cc @rullzer
@blizzz: The calendar app was automatically updated, see the list of enabled apps in the issue description.
@PVince81:
Looked into my owncloud.log but seems like all update related logs are already overwritten by other events.
Would #23008 work with 9.0.0? Can I copy the file to the right directory for testing?
@Grot4x this is better, don't just replace files:
% wget https://github.com/owncloud/core/pull/23008.patch
% patch -p1 < 23008.patch
Applied #23016 (which is the same as #23008 for OC 9.0) but this didn't fix this issue for me.
Status:
Old owncloud users (regular user) can't sync with dav while the web interface still works.
New owncloud users (regular user) can sync with dav and the web interface works.
% curl -u $ocusername -X PROPFIND https://$ochost/remote.php/dav/calendars/$ocusername/
only works for new user for older users its still empty.
So the migration might have failed? Is there a way to check that in the DB?
@Grot4x select * from oc_calendars
Did that already and it seems to be ok all calenders are available.
Can't see any difference comparing the old calendars to the new one.
select * from oc_clndr_calendars which is the old table(?)
has the same calendars except the new one I created with the new user.
select * from oc_clndr_calendars which is the old table(?)
Yes it's the old one. Try running those: https://gist.github.com/MorrisJobke/4ef8740f4e9dad291896
@nickvergessen Seems to be fine COUNT(o.calendarid) is equal. Id's changed but that shouldn't be a problem and well there is the new structure of oc_calendars but all the old calendars are in the new table.
Also why can I see my calendars in the web:
@dataflake The web interface is from the calendar GUI app: https://github.com/owncloud/calendar
It already uses Caldav, so not sure why it wouldn't aknowledge the calendar's existence.
Does the new app still use the old tables (as fall back)? I could rename them for testing.
Edit: renamed old tables but still the same problem
I have removed and recreated the LDAP settings in the Admin web interface to make sure there's no error in the user_ldap settings migration. One thing changed, I am no longer getting any of the LDAP-related error messages in owncloud.log. But Apache still shows a 404:
192.168.168.32 - [email protected] [09/Mar/2016:15:05:50 +0000] "PROPFIND /remote.php/dav/ HTTP/1.1" 207 563
192.168.168.32 - [email protected][09/Mar/2016:15:05:50 +0000] "PROPFIND /remote.php/dav/principals/users/user%40ldap.server/ HTTP/1.1" 404 240
More debugging: When dialing up the log level I now see a message that the DN for the user account could not be found:
{"reqId":"VuBM@72snAFQbThllnymPAAAAAA","remoteAddr":"192.168.168.32","app":"user_ldap","message":"initializing paged search for Filter (|(objectclass=zetworkMailPerson)) base Array\n(\n [0] => [email protected],ou=users,dc=example,dc=com\n)\n attr Array\n(\n [0] => \n)\n limit 500 offset 0","level":0,"time":"2016-03-09T16:19:07+00:00","method":"PROPFIND","url":"\/remote.php\/dav\/calendars\/user%40ldap.server\/"}
{"reqId":"VuBM@72snAFQbThllnymPAAAAAA","remoteAddr":"192.168.168.32","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-09T16:19:07+00:00","method":"PROPFIND","url":"\/remote.php\/dav\/calendars\/user%40ldap.server\/"}
{"reqId":"VuBM@72snAFQbThllnymPAAAAAA","remoteAddr":"192.168.168.32","app":"user_ldap","message":"readAttribute: [email protected],ou=users,dc=example,dc=com found","level":0,"time":"2016-03-09T16:19:07+00:00","method":"PROPFIND","url":"\/remote.php\/dav\/calendars\/user%40ldap.server\/"}
{"reqId":"VuBM@72snAFQbThllnymPAAAAAA","remoteAddr":"192.168.168.32","app":"user_ldap","message":"Base tree for Groups is empty, using Base DN","level":1,"time":"2016-03-09T16:19:07+00:00","method":"PROPFIND","url":"\/remote.php\/dav\/calendars\/user%40ldap.server\/"}
{"reqId":"VuBM@72snAFQbThllnymPAAAAAA","remoteAddr":"192.168.168.32","app":"user_ldap","message":"Base tree for Groups is empty, using Base DN","level":1,"time":"2016-03-09T16:19:07+00:00","method":"PROPFIND","url":"\/remote.php\/dav\/calendars\/user%40ldap.server\/"}
{"reqId":"VuBM@72snAFQbThllnymPAAAAAA","remoteAddr":"192.168.168.32","app":"user_ldap","message":"No DN found for [email protected] on ldap:\/\/127.0.0.1","level":0,"time":"2016-03-09T16:19:08+00:00","method":"PROPFIND","url":"\/remote.php\/dav\/calendars\/user%40ldap.server\/"}
This is odd because it clearly found the record as a whole, and even doing debug logging on my LDAP server I don't see any search or read request that gets denied for any reason (acl etc). What does the app do to determine the DN? Or maybe what does it do differently compared to OC 8.2.2 where this worked?
For me calendar are working properly, but yes contacts are broken with the same 404.
It's very anoying, i notice this after a phone wipe to resync all my contacts... :(
DB: pgsql 9.5, apache 2.4, PHP 5.4.19
I have the same problem with calendar and contacts sync via CalDAV/CardDAV since the update to OC 9.0. It seems to be related / restricted to LDAP-users:
curl -u <ldap-user> -X PROPFIND https://owncloud.tld/remote.php/dav/calendars/<ldap-user>/
produces an authentication error:
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\NotAuthenticated</s:exception>
<s:message>Username or password was incorrect, Username or password was incorrect</s:message>
</d:error>
Doing the same with a local user (not authenticated via LDAP) works as expected and produces the list of available calendars.
PS: Ubuntu 14.04, Apache/2.4.7, PHP 5.5.9-1ubuntu4.14, MySQL 5.6.28-ubuntu0.14.04.1
I added
Redirect /remote.php/dav/addressbooks/users /remote.php/carddav/addressbooks
to my apache configuration to fix the endpoint issue with carddav :). But this is just a workaround
Note: this workaround works with Carddav sync but it seems not davdroid
I tried to reproduce it yesterday with LDAP users, however without upgrading. Did not work. I give it a try with upgrading today.
FYI, since I could still access the calendars using the web interface I exported all of them, created a non-LDAP user and reimported them there. Now it all works. There's a definite issue with the user_ldap module.
But I have the same problem with old non-LDAP users which existed before the upgrade.
I can access the web interface but not dav. A new created user can access dav and web interface.
@dataflake If you create a new LDAP user is he able to use dav?
@Grot4x No, see comment https://github.com/owncloud/core/issues/22988#issuecomment-194272760
I also have a lingering suspicion that my username scheme (it's an email address) may cause problems, but that may be a totally separate issue. Sometimes I see the _@_ quoted as _%40_, and sometimes URLs contain the user's long UID instead of the login name. Furthermore, the user creation scripts don't explicitly allow "." in a username, but they do allow "@".
@Grot4x i got the same issue. but it dos not work for new created users too.. i was using it to access my calendar with my thunderbird client (lightning-plugin) after the upgrade, the calendars cant be "shared" via dav. even the "Caldav-link icon" is disappeared (https://doc.owncloud.org/server/9.0/user_manual/pim/calendar.html "Getting the Caldav-Link")
is there any working fix/workaround?
i can confirm that @dataflake with very similar setup (using regular logins, not email addresses), normal users can sync via lightning and davdroid, ldap users sync initially in lightning, but after a while the calendar become unavaliable. with davdroid (and ldap) i can add calendars, but never syncs.
in web server logs, PROPFIND on calendar returns 404 (but REPORT does ok):
"PROPFIND /remote.php/dav/calendars/a99b453a-851d-1034-820a-ef8eff48eb9e/ HTTP/2.0" 207
"REPORT /remote.php/dav/calendars/a99b453a-851d-1034-820a-ef8eff48eb9e/personal/ HTTP/2.0" 207
"PROPFIND /remote.php/caldav/calendars/a99b453a-851d-1034-820a-ef8eff48eb9e/personal/ HTTP/1.1" 404
curl -u misotolar -X PROPFIND https://$ochost/remote.php/dav/calendars/a99b453a-851d-1034-820a-ef8eff48eb9e/personal
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\NotFound</s:exception>
<s:message>Principal with name misotolar not found</s:message>
</d:error>
@Marcwa19197 My old and new users don't have the share button.
Is the "Primary CalDAV" working for you (new user/old user)?
@Grot4x, @Marcwa19197 I can see caldav link in tooltip on calendar's name
@Grot4x no, it is not working in thunderbird, calendar seems to be "unavailable", and calendars viewed via my BlackBerry Passport are not available anymore too..
@misotolar i see it too in the tooltip, but the icon on the right is disapeared, also the "Rename" icon is not there anymore..
Here a Screenshot, both Calendars are created newly with an old account.

@Marcwa19197 Ok, and if you create a new user does it work for him?
Because so far it seems to work for new owncloud users but not for LDAP-users old/new and old owncloud users.
@Grot4x no, for new users the same issue occures.. im not using LDAP, only local owncloud users.
Well thats strange...
even if i create a new user, he will have a "default-named" calendar and there are the icons for "renaming" and "Caldav-Link" missing too..
i upgraded from 8.2.2 to 9.0.0 with the .tar.gz file, but using the old config.php and old mysql-database.
For my new user the button is missing but i can use dav over /remote.php/dav/
is your domain scheme like "domain.tld/remote.php/dav/"?
mine is like "domain.tld/cloud/remote.php/dav" i read something about "well-known URLS"? maybe that is the point?
The URL scheme changed and it seems like the old URLs are not redirected to the new one so thats the first issue why your calendar is not working. In the settings of you calendar app you will find a url domain.tld/cloud/remote.php/dav which also seems not to work for old users.
But my new user can use this url. Could you try this for your new created user:
curl -u $name -X PROPFIND https://domain.tld/cloud/remote.php/dav/
Response seems to be good, is it maybe a problem with thunderbird itself?
http://pastebin.com/jgnDQPq8
Edit:
For an old user, output seems to be the same
@Marcwa19197 in thunderbird i can sync regular user's calendars using this url:
https://domain.tld/cloud/remote.php/dav/calendars/[username]/[calendar name]
@misotolar i tryed it with the newly created user "test" and a calendar called "test-cal" with following url:
https://www.domain.de/cloud/remote.php/dav/calendars/test/test-cal/ in thunderbird the calendar seems to be "disabled/unavailable"..
@Marcwa19197 you can see the calendar's caldav link on mouseover calendar's name in owncloud sidebar, is the same?
@misotolar nope, it is like:
https://www.domain.de/cloud/remote.php/davhp/dav/calendars/test/test-cal/
a test with this URL and the command
curl -u test -X PROPFIND https://www.domain.de/cloud/remote.php/davhp/dav/calendars/test/test-cal/
returns an html site from owncloud which display
"App not installed: "
Strange, I don't know from where the davhp string comes but didn't seems to be correct...
here the output of the sql query above, if it is useful..
before upgrading to 8.2.2 i was using "calendarplus", but i dont thing that this is the problem.
maybe it is a general database migration bug? i think i use the same mysql-database since version 6..
select * from oc_appconfig where appid='core' and configkey like 'remote_cal%';

@Marcwa19197 Are your calendars in select * from oc_calendars?
@Grot4x yes, all calendars are shown as below

Edit:
Okay, i tested it with a different Owncloud installation, upgraded via tar.gz from 8.0 to 9.0, strange thing happens here on a newly created user:
http://domain.de/owncloud/remote.php/dave.php/dav/calendars/marcwa/testEdit2:
Strange things happen here..
We just upgraded to 9.0 today and had the same/similar problem, though only for LDAP users. We could fix it by setting a "Internal Username Attribute" (in our case to sAMAccountName) and clearing existing Username-LDAP User Mappings.
The problem was that the login was the sAMAccountName, whereas the links included the UUID. The above change fixed that.
Another note: we had to update our nginx config (rewrite rules for .well-known urls).
Strange, I don't know from where the davhp string comes but didn't seems to be correct...
this looks like a url rewrite and/or procy config issue
@mheckel clearing existing username-ldap user mappings? what exactly do you mean by that?

In the meanwhile we switched to another attribute, which is more likely to be unique in our directory.
Please note: changing the attribute and clearing the mapping may result in data loss (e.g. calendars, home folder, etc.) We have a completely fresh install, so this is not a deal breaker for us.
thanks! as you say, this only can be done on fresh install without any user data...
So I did a clean install of 8.2.3, enabled only LDAP and Calendar. Shared one calendar of a local user with an LDAP one and vice versa, plus few personal unshare calendars. Made entries everywhere. Configured both calendars in KOrganizer.
Did the upgrade to 9.0. Aside of an exception informing that no contacts table could be found (correct), the update process did not leave odd marks.
Back to KOrganizer, the calendars of the local user vanished all (in fact the whole calendar resource). The one of the LDAP user was still available, except entries shared by the local user. However: events created in KOrganizer were not synced up to ownCloud.
Trying to revive the calendar resource of the local user within KOrganizer I tried to fetch the calendars, without luck. But these lines appeared in the log (note, local user, credentials were correct):
{"reqId":"SCcBHkgn2wbzGmi9fD3H","remoteAddr":"127.0.0.1","app":"caldav","message":"Exception: {\"Message\":\"HTTP\1.1 401 No 'Authorization: Basic' header found. Either the client didn't send one, or the server is mis-configured\",\"Exception\":\"Sabre\DAV\Exception\NotAuthenticated\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\DAV\Auth\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#1 \srv\http\dev\caltest\3rdparty\sabre\event\lib\EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#2 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Server.php(446): Sabre\Event\EventEmitter->emit('beforeMethod', Array)\
#3 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#4 \srv\http\dev\caltest\apps\dav\appinfo\v1\caldav.php(75): Sabre\DAV\Server->exec()\
#5 \srv\http\dev\caltest\remote.php(138): require_once('\srv\http\dev\c...')\
#6 {main}\",\"File\":\"\srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Auth\Plugin.php\",\"Line\":188,\"User\":false}","level":0,"time":"2016-03-10T22:04:55+00:00","method":"PROPFIND","url":"\caltest\remote.php\caldav\"}
{"reqId":"OGDGCPkX8x41mosFvZWR","remoteAddr":"127.0.0.1","app":"caldav","message":"Exception: {\"Message\":\"HTTP\1.1 401 No 'Authorization: Basic' header found. Either the client didn't send one, or the server is mis-configured\",\"Exception\":\"Sabre\DAV\Exception\NotAuthenticated\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\DAV\Auth\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#1 \srv\http\dev\caltest\3rdparty\sabre\event\lib\EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#2 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Server.php(446): Sabre\Event\EventEmitter->emit('beforeMethod', Array)\
#3 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#4 \srv\http\dev\caltest\apps\dav\appinfo\v1\caldav.php(75): Sabre\DAV\Server->exec()\
#5 \srv\http\dev\caltest\remote.php(138): require_once('\srv\http\dev\c...')\
#6 {main}\",\"File\":\"\srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Auth\Plugin.php\",\"Line\":188,\"User\":false}","level":0,"time":"2016-03-10T22:04:56+00:00","method":"PROPFIND","url":"\caltest\remote.php\caldav\principals\users\admin\"}
{"reqId":"Uu9EqY+lnyLo14f3OQe3","remoteAddr":"127.0.0.1","app":"user_ldap","message":"No DN found for users on ldap:\172.16.107.6","level":0,"time":"2016-03-10T22:04:56+00:00","method":"PROPFIND","url":"\caltest\remote.php\caldav\principals\users\admin\"}
{"reqId":"Uu9EqY+lnyLo14f3OQe3","remoteAddr":"127.0.0.1","app":"user_ldap","message":"No DN found for users on ldap:\172.16.107.6","level":0,"time":"2016-03-10T22:04:56+00:00","method":"PROPFIND","url":"\caltest\remote.php\caldav\principals\users\admin\"}
{"reqId":"Uu9EqY+lnyLo14f3OQe3","remoteAddr":"127.0.0.1","app":"caldav","message":"Exception: {\"Message\":\"HTTP\1.1 404 Principal with name users not found\",\"Exception\":\"Sabre\DAV\Exception\NotFound\",\"Code\":0,\"Trace\":\"#0 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Tree.php(76): Sabre\DAVACL\AbstractPrincipalCollection->getChild('users')\
#1 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Tree.php(71): Sabre\DAV\Tree->getNodeForPath('principals\user...')\
#2 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Server.php(903): Sabre\DAV\Tree->getNodeForPath('principals\user...')\
#3 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\CorePlugin.php(336): Sabre\DAV\Server->getPropertiesForPath('principals\user...', Array, 0)\
#4 [internal function]: Sabre\DAV\CorePlugin->httpPropFind(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#5 \srv\http\dev\caltest\3rdparty\sabre\event\lib\EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#6 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Server.php(459): Sabre\Event\EventEmitter->emit('method:PROPFIND', Array)\
#7 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#8 \srv\http\dev\caltest\apps\dav\appinfo\v1\caldav.php(75): Sabre\DAV\Server->exec()\
#9 \srv\http\dev\caltest\remote.php(138): require_once('\srv\http\dev\c...')\
#10 {main}\",\"File\":\"\srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAVACL\AbstractPrincipalCollection.php\",\"Line\":118,\"User\":\"admin\"}","level":0,"time":"2016-03-10T22:04:56+00:00","method":"PROPFIND","url":"\caltest\remote.php\caldav\principals\users\admin\"}
{"reqId":"0+6sG82zi9lbNEB8lS\B","remoteAddr":"127.0.0.1","app":"caldav","message":"Exception: {\"Message\":\"HTTP\1.1 401 No 'Authorization: Basic' header found. Either the client didn't send one, or the server is mis-configured\",\"Exception\":\"Sabre\DAV\Exception\NotAuthenticated\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\DAV\Auth\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#1 \srv\http\dev\caltest\3rdparty\sabre\event\lib\EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#2 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Server.php(446): Sabre\Event\EventEmitter->emit('beforeMethod', Array)\
#3 \srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#4 \srv\http\dev\caltest\apps\dav\appinfo\v1\caldav.php(75): Sabre\DAV\Server->exec()\
#5 \srv\http\dev\caltest\remote.php(138): require_once('\srv\http\dev\c...')\
#6 {main}\",\"File\":\"\srv\http\dev\caltest\3rdparty\sabre\dav\lib\DAV\Auth\Plugin.php\",\"Line\":188,\"User\":false}","level":0,"time":"2016-03-10T22:04:56+00:00","method":"PROPFIND","url":"\caltest\remote.php\caldav\"}
Back to the LDAP user. Although calendars were still present and visible in KOrganizer, it stopped to sync both up and down. Trying to force a sync from the client results in nothing. Fetching Calendars here results in a similar output as above, however including a 404:
{"reqId":"qAGJwqGvlq/p2rCX8waM","remoteAddr":"127.0.0.1","app":"caldav","message":"Exception: {\"Message\":\"HTTP\/1.1 401 No 'Authorization: Basic' header found. Either the client didn't send one, or the server is mis-configured\",\"Exception\":\"Sabre\DAV\Exception\NotAuthenticated\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\DAV\Auth\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#1 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#2 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(446): Sabre\Event\EventEmitter->emit('beforeMethod', Array)\
#3 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#4 \/srv\/http\/dev\/caltest\/apps\/dav\/appinfo\/v1\/caldav.php(75): Sabre\DAV\Server->exec()\
#5 \/srv\/http\/dev\/caltest\/remote.php(138): require_once('\/srv\/http\/dev\/c...')\
#6 {main}\",\"File\":\"\/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Auth\/Plugin.php\",\"Line\":188,\"User\":false}","level":0,"time":"2016-03-10T22:10:58+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(objectclass=inetOrgPerson))(|(|(memberof=CN=Squadron 2,OU=squadrons,DC=zombieland,DC=owncloud)(primaryGroupID=1031280)))) base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(objectclass=inetOrgPerson))(|(|(memberof=CN=Squadron 2,OU=squadrons,DC=zombieland,DC=owncloud)(primaryGroupID=1031280)))) base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => primaryGroupID
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => dc=zombieland,dc=owncloud
)
attr Array
(
[0] => objectsid
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(cn=Squadron 2))(objectsid=S-1-5-21-3899701326-753552600-1713145220-513)) base Array
(
[0] => DC=zombieland,DC=owncloud
)
attr Array
(
[0] => dn
)
limit 1 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => memberOf
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (|(cn=Squadron 2)) base Array
(
[0] => cn=squadron 2,ou=squadrons,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => cn
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=squadron 2,ou=squadrons,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=squadron 2,ou=squadrons,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(objectclass=inetOrgPerson))(|(|(memberof=CN=Squadron 2,OU=squadrons,DC=zombieland,DC=owncloud)(primaryGroupID=1031280)))) base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => displayName
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"sP/KoiKqS926xpcemx+E","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:10:59+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"SZrHvHlinr340WpJE/Iv","remoteAddr":"127.0.0.1","app":"caldav","message":"Exception: {\"Message\":\"HTTP\/1.1 401 No 'Authorization: Basic' header found. Either the client didn't send one, or the server is mis-configured\",\"Exception\":\"Sabre\DAV\Exception\NotAuthenticated\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\DAV\Auth\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#1 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#2 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(446): Sabre\Event\EventEmitter->emit('beforeMethod', Array)\
#3 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#4 \/srv\/http\/dev\/caltest\/apps\/dav\/appinfo\/v1\/caldav.php(75): Sabre\DAV\Server->exec()\
#5 \/srv\/http\/dev\/caltest\/remote.php(138): require_once('\/srv\/http\/dev\/c...')\
#6 {main}\",\"File\":\"\/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Auth\/Plugin.php\",\"Line\":188,\"User\":false}","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(objectclass=inetOrgPerson))(|(|(memberof=CN=Squadron 2,OU=squadrons,DC=zombieland,DC=owncloud)(primaryGroupID=1031280)))) base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(objectclass=inetOrgPerson))(|(|(memberof=CN=Squadron 2,OU=squadrons,DC=zombieland,DC=owncloud)(primaryGroupID=1031280)))) base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => primaryGroupID
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => dc=zombieland,dc=owncloud
)
attr Array
(
[0] => objectsid
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(cn=Squadron 2))(objectsid=S-1-5-21-3899701326-753552600-1713145220-513)) base Array
(
[0] => DC=zombieland,DC=owncloud
)
attr Array
(
[0] => dn
)
limit 1 offset 0","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => memberOf
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (|(cn=Squadron 2)) base Array
(
[0] => cn=squadron 2,ou=squadrons,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => cn
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=squadron 2,ou=squadrons,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=squadron 2,ou=squadrons,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(objectclass=inetOrgPerson))(|(|(memberof=CN=Squadron 2,OU=squadrons,DC=zombieland,DC=owncloud)(primaryGroupID=1031280)))) base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:00+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => displayName
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"No DN found for users on ldap://172.16.107.6","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"user_ldap","message":"No DN found for users on ldap://172.16.107.6","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"4/fPPXzFTEv8BUFdYMEP","remoteAddr":"127.0.0.1","app":"caldav","message":"Exception: {\"Message\":\"HTTP\/1.1 404 Principal with name users not found\",\"Exception\":\"Sabre\DAV\Exception\NotFound\",\"Code\":0,\"Trace\":\"#0 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Tree.php(76): Sabre\DAVACL\AbstractPrincipalCollection->getChild('users')\
#1 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Tree.php(71): Sabre\DAV\Tree->getNodeForPath('principals\/user...')\
#2 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(903): Sabre\DAV\Tree->getNodeForPath('principals\/user...')\
#3 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/CorePlugin.php(336): Sabre\DAV\Server->getPropertiesForPath('principals\/user...', Array, 0)\
#4 [internal function]: Sabre\DAV\CorePlugin->httpPropFind(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#5 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#6 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(459): Sabre\Event\EventEmitter->emit('method:PROPFIND', Array)\
#7 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#8 \/srv\/http\/dev\/caltest\/apps\/dav\/appinfo\/v1\/caldav.php(75): Sabre\DAV\Server->exec()\
#9 \/srv\/http\/dev\/caltest\/remote.php(138): require_once('\/srv\/http\/dev\/c...')\
#10 {main}\",\"File\":\"\/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAVACL\/AbstractPrincipalCollection.php\",\"Line\":118,\"User\":\"24B661A8-5F80-4333-A2CB-4A616543F674\"}","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/principals/users/zombie_135360/"}
{"reqId":"8faO0HruqAIlyzW4DUTa","remoteAddr":"127.0.0.1","app":"caldav","message":"Exception: {\"Message\":\"HTTP\/1.1 401 No 'Authorization: Basic' header found. Either the client didn't send one, or the server is mis-configured\",\"Exception\":\"Sabre\DAV\Exception\NotAuthenticated\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\DAV\Auth\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#1 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#2 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(446): Sabre\Event\EventEmitter->emit('beforeMethod', Array)\
#3 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#4 \/srv\/http\/dev\/caltest\/apps\/dav\/appinfo\/v1\/caldav.php(75): Sabre\DAV\Server->exec()\
#5 \/srv\/http\/dev\/caltest\/remote.php(138): require_once('\/srv\/http\/dev\/c...')\
#6 {main}\",\"File\":\"\/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Auth\/Plugin.php\",\"Line\":188,\"User\":false}","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(objectclass=inetOrgPerson))(|(|(memberof=CN=Squadron 2,OU=squadrons,DC=zombieland,DC=owncloud)(primaryGroupID=1031280)))) base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(objectclass=inetOrgPerson))(|(|(memberof=CN=Squadron 2,OU=squadrons,DC=zombieland,DC=owncloud)(primaryGroupID=1031280)))) base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:11:01+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => primaryGroupID
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => dc=zombieland,dc=owncloud
)
attr Array
(
[0] => objectsid
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(cn=Squadron 2))(objectsid=S-1-5-21-3899701326-753552600-1713145220-513)) base Array
(
[0] => DC=zombieland,DC=owncloud
)
attr Array
(
[0] => dn
)
limit 1 offset 0","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => memberOf
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (|(cn=Squadron 2)) base Array
(
[0] => cn=squadron 2,ou=squadrons,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => cn
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=squadron 2,ou=squadrons,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=squadron 2,ou=squadrons,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter (&(|(objectclass=inetOrgPerson))(|(|(memberof=CN=Squadron 2,OU=squadrons,DC=zombieland,DC=owncloud)(primaryGroupID=1031280)))) base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] =>
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"readAttribute: cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud found","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"initializing paged search for Filter objectClass=* base Array
(
[0] => cn=adam raith,ou=okunoin,ou=cemeteries,dc=zombieland,dc=owncloud
)
attr Array
(
[0] => displayName
)
limit 500 offset 0","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"Ready for a paged search","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"user_ldap","message":"No DN found for zombie_135360 on ldap://172.16.107.6","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
{"reqId":"UcT6l70ncNWFxOpmEexD","remoteAddr":"127.0.0.1","app":"caldav","message":"Exception: {\"Message\":\"HTTP\/1.1 404 Principal with name zombie_135360 not found\",\"Exception\":\"Sabre\DAV\Exception\NotFound\",\"Code\":0,\"Trace\":\"#0 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Tree.php(76): Sabre\DAVACL\AbstractPrincipalCollection->getChild('zombie_135360')\
#1 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAVACL\/Plugin.php(289): Sabre\DAV\Tree->getNodeForPath('principals\/zomb...')\
#2 \/srv\/http\/dev\/caltest\/apps\/dav\/lib\/connector\/legacydavacl.php(59): Sabre\DAVACL\Plugin->getPrincipalMembership('principals\/zomb...')\
#3 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAVACL\/Plugin.php(511): OCA\DAV\Connector\LegacyDAVACL->getCurrentUserPrincipals()\
#4 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAVACL\/Plugin.php(189): Sabre\DAVACL\Plugin->getCurrentUserPrivilegeSet('principals')\
#5 \/srv\/http\/dev\/caltest\/apps\/dav\/lib\/connector\/sabre\/davaclplugin.php(48): Sabre\DAVACL\Plugin->checkPrivileges('principals', '{DAV:}read', 1, false)\
#6 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAVACL\/Plugin.php(844): OCA\DAV\Connector\Sabre\DavAclPlugin->checkPrivileges('principals', '{DAV:}read', 1, false)\
#7 [internal function]: Sabre\DAVACL\Plugin->propFind(Object(Sabre\DAV\PropFind), Object(Sabre\CalDAV\Principal\Collection))\
#8 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#9 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(999): Sabre\Event\EventEmitter->emit('propFind', Array)\
#10 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(919): Sabre\DAV\Server->getPropertiesByNode(Object(Sabre\DAV\PropFind), Object(Sabre\CalDAV\Principal\Collection))\
#11 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/CorePlugin.php(336): Sabre\DAV\Server->getPropertiesForPath('', Array, 1)\
#12 [internal function]: Sabre\DAV\CorePlugin->httpPropFind(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#13 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\
#14 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(459): Sabre\Event\EventEmitter->emit('method:PROPFIND', Array)\
#15 \/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\
#16 \/srv\/http\/dev\/caltest\/apps\/dav\/appinfo\/v1\/caldav.php(75): Sabre\DAV\Server->exec()\
#17 \/srv\/http\/dev\/caltest\/remote.php(138): require_once('\/srv\/http\/dev\/c...')\
#18 {main}\",\"File\":\"\/srv\/http\/dev\/caltest\/3rdparty\/sabre\/dav\/lib\/DAVACL\/AbstractPrincipalCollection.php\",\"Line\":118,\"User\":\"24B661A8-5F80-4333-A2CB-4A616543F674\"}","level":0,"time":"2016-03-10T22:11:02+00:00","method":"PROPFIND","url":"/caltest/remote.php/caldav/"}
What catches my attention is that in both cases, local and LDAP, apparently a user called "users" is lookup up. Without success, unsurprisingly.
I fixed all my carddav issues by fixing UID in oc_cards_properties and all uri in oc_cards replacing all full URI by
I fixed all my carddav issues by fixing UID in oc_cards_properties and all uri in oc_cards replacing all full URI by vcf like new entries (thanks regexp in pgsql)
What do you mean with "vcf"? Can you provide your fix please?
I am stuck with the same problem. The web interface works fine and it seems to use caldav. The request headers start with:
PROPFIND /owncloud/remote.php/dav/calendars/florz/ HTTP/1.1
This gives back a list of my calendars. However if I try to execute the same request using curl I end up with this:
# curl -u Florz -X PROPFIND https://XXXX/owncloud/remote.php/dav/calendars/florz/
Enter host password for user 'Florz':
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\NotFound</s:exception>
<s:message>Node with name 'florz' could not be found</s:message>
</d:error>
At the same time I get this error message:
Exception: {"Message":"HTTP\/1.1 404 Node with name 'florz' could not be found","Exception":"Sabre\\DAV\\Exception\\NotFound","Code":0,"Trace":"#0 \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAVACL\/Plugin.php(844): OCA\\DAV\\Connector\\Sabre\\DavAclPlugin->checkPrivileges('calendars\/florz', '{DAV:}read', 1, false)\n#1 [internal function]: Sabre\\DAVACL\\Plugin->propFind(Object(Sabre\\DAV\\PropFind), Object(OCA\\DAV\\CalDAV\\CalendarHome))\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(999): Sabre\\Event\\EventEmitter->emit('propFind', Array)\n#4 \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(919): Sabre\\DAV\\Server->getPropertiesByNode(Object(Sabre\\DAV\\PropFind), Object(OCA\\DAV\\CalDAV\\CalendarHome))\n#5 \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/CorePlugin.php(336): Sabre\\DAV\\Server->getPropertiesForPath('calendars\/florz', Array, 1)\n#6 [internal function]: Sabre\\DAV\\CorePlugin->httpPropFind(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\n#7 \/var\/www\/owncloud\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#8 \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(459): Sabre\\Event\\EventEmitter->emit('method:PROPFIND', Array)\n#9 \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(248): Sabre\\DAV\\Server->invokeMethod(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\n#10 \/var\/www\/owncloud\/apps\/dav\/lib\/server.php(137): Sabre\\DAV\\Server->exec()\n#11 \/var\/www\/owncloud\/apps\/dav\/appinfo\/v2\/remote.php(29): OCA\\DAV\\Server->exec()\n#12 \/var\/www\/owncloud\/remote.php(138): require_once('\/var\/www\/ownclo...')\n#13 {main}","File":"\/var\/www\/owncloud\/apps\/dav\/lib\/connector\/sabre\/davaclplugin.php","Line":61,"User":"florz"}
PS:
It seems migration went without problems:
# MYSQL_PWD=XXX mysql -u XXX owncloud < analyse-owncloud-calendar-migration.sql
calendarid userid displayname uri COUNT(o.calendarid)
12 florz AAA aaa 103
1 florz privat defaultcalendar 611
calendarid principaluri displayname uri description COUNT(o.calendarid)
3 principals/users/florz AAA aaa AAA 103
2 principals/users/florz privat defaultcalendar privat 611
@Florz if i do the same check, with your url scheme, i get a valid response, but thunderbird still say the calendar is unavailable..
EDIT!:
It works, i used the following url-scheme in Thunderbird.
https://domain.de/cloud/remote.php/dav/calendars/Marcwa19197/privat/
Thunderbird asks for login information, and the events are synced.
But still the tooltip URL shows something different.
(https://www.domain.de/cloud/remote.php/davhp/dav/calendars/Marcwa19197/privat/)
Note: owncloud account Marcwa19197 is an old, existing one since OC6.
So the only problem i have right now:

@Florz - I upgraded from 8.2 to 9.0 this morning. Nothing works yet to bring back calendars. Have you found a fix yet?
$ curl -u myuser -X PROPFIND https://host.com/remote.php/dav/calendars/myuser/
Enter host password for user 'myuser':
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\NotFound</s:exception>
<s:message>Principal with name myuser not found</s:message>
</d:error>
Seems that I found bug: auth login is case insensitive, but ACL - yes.
Try to enter login exacly as it's stored in DB. In my case it was solution. But it's must be fixed in core.
Details: https://github.com/owncloud/core/issues/23147#issuecomment-195572329
@Marcwa19197 thanks for the tip! You were right. I had to type my username with a small "f". That fixed it.
@devuan2 with the correct username I was able to use this URL for my default calendar (also notice the small "f" in my username here):
https://domainname.tld/owncloud/remote.php/dav/calendars/florz/defaultcalendar/
I had lots of (similar) issues on 8.2.2-->9.0 upgrade on Ubuntu 14.04. I logged a bug with the calendar repo: https://github.com/owncloud/contacts/issues/199
Contacts are actually there, they just take a long time to show up (and the UI says there are no contacts during that time).
I have encountered the same issue after upgrading from owncloud 8 to owncloud 9.0. The upgrade and migration was successfully but trying to access CalDAV or CardDAV with existing LDAP users just results in "404 Principal with name $name not found", for regular owncloud users it works.
I spent a few hours digging through the code yesterday but either due to the complexity of the owncloud code or my lack of php knowledge, I couldn't find the difference between the two versions which cause these issues. The error itself is reported in AbstractPrincipalCollection.php but there seem to be no relevant differences in this file or the getChild method compared to earlier versions. So I guess something should have happened until this method is called which doesn't happen any more or the other way around, something should happen in the code called by this method which doesn't happen any more.
Since contacts and calendar synchronization are major selling points for the users of my owncloud instance, this causes major issues for me. If anyone could provide a work-around for the issue or a preliminary patch, I would be happy to test it. Also, if you need any additional information, I will gladly provide it.
same issue, using LDAP authentication. :( Gonna have a user revolt tomorrow!!
It seems like maybe it's because the username I log in with is not the same as the username that it uses in the URL (which is a GUID thing)
curl gives me this to any url that has the guid in it:
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\NotFound</s:exception>
<s:message>Principal with name dwalker not found</s:message>
</d:error>
anyone else expecting very very slow webdav connection with webdav-clients?
Exactly the same issues for me after a migration from 8.2.2 to 9.0. I have ldap users all lowercase.
Contact page is slow, so I guess webdav clients should be slow as AFAIK js web client is also using webdav.
I tried several carddav configurations. E.g. OC9 told me to use https://example.com/subfolder/remote.php/dav/addressbooks/users/username/kontakte/ in contacts settings.
But only using this url I was successful (OSX 10.11):
carddavs://example.com/subfolder/remote.php/dav/
Source: https://github.com/owncloud/documentation/blob/master/user_manual/pim/contacts.rst#synchronizing-with-android
Contact page is slow, so I guess webdav clients should be slow as AFAIK js web client is also using webdav.
i have slow connection from an android app called "ES file explorer".. after a apache2 restart everything works fast as it should be.. but after 5 minutes its slow as hell again..
I managed to have access to the vcards with a webdav client (dolphin) with the following url:
webdavs://USERNAME@SERVER/remote.php/dav/addressbooks/users/LDAPUID/ADDRESSBOOKNAME/
So I guess there's something wrong with username mapping
Hi guys,
I have been following this thread and I did some further debugging.
The actual issue is:
$ curl -u tom -X PROPFIND https://owncloud.tld/remote.php/dav/principals/users/d3e277de-400c-1033-87f3-9b1f5d31dfa1/
Enter host password for user 'tom':
#0 Sabre\DAVACL\AbstractPrincipalCollection->getChild() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Collection.php:54]
#1 Sabre\DAV\Collection->childExists() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Tree.php:105]
#2 Sabre\DAV\Tree->nodeExists() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:730]
#3 Sabre\DAVACL\Plugin->beforeMethod()
#4 call_user_func_array() called at [/var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php:105]
#5 Sabre\Event\EventEmitter->emit() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:446]
#6 Sabre\DAV\Server->invokeMethod() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:248]
#7 Sabre\DAV\Server->exec() called at [/var/www/owncloud/apps/dav/lib/server.php:137]
#8 OCA\DAV\Server->exec() called at [/var/www/owncloud/apps/dav/appinfo/v2/remote.php:29]
#9 require_once(/var/www/owncloud/apps/dav/appinfo/v2/remote.php) called at [/var/www/owncloud/remote.php:138]
#0 Sabre\DAVACL\AbstractPrincipalCollection->getChild() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Tree.php:76]
#1 Sabre\DAV\Tree->getNodeForPath() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:903]
#2 Sabre\DAV\Server->getPropertiesForPath() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php:336]
#3 Sabre\DAV\CorePlugin->httpPropFind()
#4 call_user_func_array() called at [/var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php:105]
#5 Sabre\Event\EventEmitter->emit() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:459]
#6 Sabre\DAV\Server->invokeMethod() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:248]
#7 Sabre\DAV\Server->exec() called at [/var/www/owncloud/apps/dav/lib/server.php:137]
#8 OCA\DAV\Server->exec() called at [/var/www/owncloud/apps/dav/appinfo/v2/remote.php:29]
#9 require_once(/var/www/owncloud/apps/dav/appinfo/v2/remote.php) called at [/var/www/owncloud/remote.php:138]
#0 Sabre\DAVACL\AbstractPrincipalCollection->getChild() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Tree.php:76]
#1 Sabre\DAV\Tree->getNodeForPath() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:289]
#2 Sabre\DAVACL\Plugin->getPrincipalMembership() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:255]
#3 Sabre\DAVACL\Plugin->getCurrentUserPrincipals() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:511]
#4 Sabre\DAVACL\Plugin->getCurrentUserPrivilegeSet() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:189]
#5 Sabre\DAVACL\Plugin->checkPrivileges() called at [/var/www/owncloud/apps/dav/lib/connector/sabre/davaclplugin.php:48]
#6 OCA\DAV\Connector\Sabre\DavAclPlugin->checkPrivileges() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:844]
#7 Sabre\DAVACL\Plugin->propFind()
#8 call_user_func_array() called at [/var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php:105]
#9 Sabre\Event\EventEmitter->emit() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:999]
#10 Sabre\DAV\Server->getPropertiesByNode() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:919]
#11 Sabre\DAV\Server->getPropertiesForPath() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php:336]
#12 Sabre\DAV\CorePlugin->httpPropFind()
#13 call_user_func_array() called at [/var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php:105]
#14 Sabre\Event\EventEmitter->emit() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:459]
#15 Sabre\DAV\Server->invokeMethod() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:248]
#16 Sabre\DAV\Server->exec() called at [/var/www/owncloud/apps/dav/lib/server.php:137]
#17 OCA\DAV\Server->exec() called at [/var/www/owncloud/apps/dav/appinfo/v2/remote.php:29]
#18 require_once(/var/www/owncloud/apps/dav/appinfo/v2/remote.php) called at [/var/www/owncloud/remote.php:138]
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">;
<s:exception>Sabre\DAV\Exception\NotFound</s:exception>
<s:message>Principal with name tom not found</s:message>
</d:error>
I hope this helps!
I will try to investigate a little deeper too...
With best regards,
Tom.
Seems to be caused by the last step:
#0 Sabre\DAVACL\AbstractPrincipalCollection->getChild() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Tree.php:76]
#1 Sabre\DAV\Tree->getNodeForPath() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:289]
#2 Sabre\DAVACL\Plugin->getPrincipalMembership() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:255]
#3 Sabre\DAVACL\Plugin->getCurrentUserPrincipals() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:511]
#4 Sabre\DAVACL\Plugin->getCurrentUserPrivilegeSet() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:189]
#5 Sabre\DAVACL\Plugin->checkPrivileges() called at [/var/www/owncloud/apps/dav/lib/connector/sabre/davaclplugin.php:48]
#6 OCA\DAV\Connector\Sabre\DavAclPlugin->checkPrivileges() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAVACL/Plugin.php:844]
#7 Sabre\DAVACL\Plugin->propFind()
#8 call_user_func_array() called at [/var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php:105]
#9 Sabre\Event\EventEmitter->emit() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:999]
#10 Sabre\DAV\Server->getPropertiesByNode() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:919]
#11 Sabre\DAV\Server->getPropertiesForPath() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php:336]
#12 Sabre\DAV\CorePlugin->httpPropFind()
#13 call_user_func_array() called at [/var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php:105]
#14 Sabre\Event\EventEmitter->emit() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:459]
#15 Sabre\DAV\Server->invokeMethod() called at [/var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:248]
#16 Sabre\DAV\Server->exec() called at [/var/www/owncloud/apps/dav/lib/server.php:137]
#17 OCA\DAV\Server->exec() called at [/var/www/owncloud/apps/dav/appinfo/v2/remote.php:29]
#18 require_once(/var/www/owncloud/apps/dav/appinfo/v2/remote.php) called at [/var/www/owncloud/remote.php:138]
Something being translated differently when checking privileges?
I can also confirm that after OC upgrade 8.2 -> 9.0 calendar, tasks and contacts shows up on the web interfaces just ok for every user but syncing with webdav/carddav clients (iOS and EmClient) do not work for the old users. If I create a new user everything works out-of-the-box, also syncing. All users are regular users in this case.
Similar issues arise when using the oC News App on iOS (owncloud/news-iOS-App#70) or Android (owncloud/News-Android-App#499): #23248
There must be something seriously wrong with the authentication of LDAP-users.
Strange notice: One user with Android reported that the sync works ok after update. Only difference we could find is that for that one user the calendar uri property has been "personal" all the time. Other users have language specific values like "henkilökohtainen" or even user name specific uri values like "Tom" etc.
The android sync to my personal calendar (which doesn't use LDAP) works fine. (I'm using iCal Import/Export Pro). I just give it the base uri and it detects all the available resources there and let's me pick, so I'm not sure what the full URI is.
This is broken for work calendars that use LDAP
@Florz
Does not work for me. I created a calendar in OC called 'testing' and tried to access it using Firefox. This used to work for 8.x to verify access to the data even though Firefox would not format it into a usable calendar.
Below is what I tried to no avail. Incidentally, I also ran the calendar "migration" again listed here as the instructions on that link showed my tables were borked for whatever reason. After upgraded to OC 9, Thunderbird would show the calendar names, but they were grayed out as if they were offline.
Created new calendar in OC web interface called _'testing'_. Added one appointment in OC.
Tried to access calendar in Thunderbid/Lightning set for ICalendar(ICS) however it does not display the appointment :
https://server/remote.php/dav/principals/users/3f21ea30-9cef-1237-20e8-61fc301a9f19/testing/
Then I tried to create the calendar in Thunderbird/Lighting using CalDAV, but Thunderbird error log says "CalDAV: Status 404 on initial PROPFIND for calendar ffff":
https://server/remote.php/dav/principals/users/3f21ea30-9cef-1237-20e8-61fc301a9f19/testing/
This should work. Note how OC converts hash to actual user name? It knows who this user is at least.
https://server/remote.php/dav/calendars/3f21ea30-9cef-1237-20e8-61fc301a9f19/testing/
_<s:message>Principal with name myuser not found</s:message>_
This calendar does not exist but shows different error message than above
https://server/remote.php/dav/calendars/3f21ea30-9cef-1237-20e8-61fc301a9f19/testingfoo/
<s:message>Node with name 'testingfoo' could not be found</s:message>
Owncloud says to use this URL on the calendar page (Primary CalDAV address):
https://server/remote.php/dav/principals/users/3f21ea30-9cef-1237-20e8-61fc301a9f19/testing/
<s:message>Principal with name myuser not found</s:message>
Owncloud says this is the IOS/OS X CalDAV Address
https://server/remote.php/dav/
"This is the WebDAV interface. It can only be accessed by WebDAV clients such as the ownCloud desktop sync client."
At this point, nothing working yet but the OC web interface.
Tried the fix proposed by mhekel above and it worked like a charm:
We just upgraded to 9.0 today and had the same/similar problem, though only for LDAP users. We could fix it by setting a "Internal Username Attribute" (in our case to sAMAccountName) and clearing existing Username-LDAP User Mappings.
The problem was that the login was the sAMAccountName, whereas the links included the UUID. The above change fixed that.
N.B. Clearing the existing mappings will essentially re-initialize the data.
If there are any code fixes for this please do not break this.
I had the same issue. I solved it by setting the "Internal Username Attribute" to uid, dumping the db, replacing all uuid fields in the dump with the corresponding uid and renaming all users files and encryption keys. I then reimported the db and it seems to be working. Not a fix for the actual issue but it shows that it is possible to get around it without clearing the mappings.
@devuan2 I saw the same symptoms in Thunderbird. I had to delete my old user name from the password store and type it again (the way it is stored in OC) after restarting Thunderbird.
@blizzz Can I ask you to help out on these LDAP issues? THX
@blizzz Can I ask you to help out on these LDAP issues? THX
sorry - you are already having a look. THX
@DeepDiver1975 Yes this seems to be the problem. My problem was fixed already. Thanks!
The fix of @jtoloe, to set the "Internal Username Attribute" to the uid-property of the LDAP-directory, replace all UUIDs by the appropriate uid in the database, and rename data directories accordingly, allows to get sync working again, however does not yet fix all problems:
For me it looks like during the check for privileges there is a lookup in oc_ldap_user_mapping missing, as it works as soon as the login name for owncloud matches the internal user name.
I added dummy users, shared the LDAP users' contacts and calenders to them, and manually changed all client URLs to the dummy users, as I would have had to change the URLs anyway (dav instead of caldav...). Cumbersome for my family installation, no option for real world installations.
On several places in the OC GUI I get the impression that the UUID-stuff is somehow mixed up, e.g. the calendars of the LDAP users are shared with the long, awkward UUID added, the user admin panel doesn't show UID but UUID, and so on. I think the UUID should be something internal and not something the user faces in everyday use.
@reuterbal "Preemptive Authentication", whatever it means, is working for me with DAVdroid.
@blizzz any update on the LDAP issues ?
I did some debugging further today, and indeed found one issue. Following the hint by @Loki3000 (https://github.com/owncloud/core/issues/22988#issuecomment-195574054) with mismatching loginname / username (which can also effect local users) I focused on the auth. Our code looks pretty good with these aspects, until at some point we return a PrincipilUri just as it was given to use by Sabre – which does not know about usernames and stuff:
Called and returned here https://github.com/owncloud/core/blob/master/apps/dav/lib/connector/sabre/auth.php#L172
A fix for this is here: https://github.com/owncloud/core/pull/23404
At this point I don't know whether it fixes one aspect of this whole issue, or just a piece of it. Testers welcome!
Hi @blizz,
I can confirm this works for me!
I can now connect to the OC contacts and calendar using dav.
Please note that the principals (in the dav url) required to refer to
the calendar is still the (internal) LDAP UUID
while the username to connect to OC is the actual UID.
As suggested by @Larx, it would be a nice enhancement to OC if the
internal usernames are kept internal
and the OC users are only faced with their actual user names.
Thanks!
With best regards,
Tom.
Tom Ghyselinck tom.[email protected] vr, 2016-03-18 at 15:39 -0700, blizzz wrote:
I did some debugging further today, and indeed found one issue.
Following the hint by @Loki3000 (#22988 (comment)) with mismatching
loginname / username (which can also effect local users) I focused on
the auth. Our code looks pretty good with these aspects, until at
some point we return a PrincipilUri just as it was given to use by
Sabre – which does not know about usernames and stuff:
https://github.com/owncloud/3rdparty/blob/0ee67806d6082675541c77d79b3
f494d760e2c28/sabre/dav/lib/DAV/Auth/Backend/AbstractBasic.php#L108
Called and returned here https://github.com/owncloud/core/blob/master
/apps/dav/lib/connector/sabre/auth.php#L172
A fix for this is here: #23404
At this point I don't know whether it fixes one aspect of this whole
issue, or just a piece of it. Testers welcome!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
@blizzz also solved my issues! lightning (thunderbird) and davdroid now syncs after changing URL.
This does not break mhekel's fix. Awesome.
Personally I believe mhekel's fix should be added to the LDAP configuration documentation. It'll "just work" without it, but as an admin (IMO) it's MUCH better if the directories in data/ match the actual login names rather than UUIDs.
@blizzz applied your patch and my clients are syncing again after adding the new url :+1:
I can confirm that #23404 of @blizzz does indeed fix the sync issues. Thanks for that!
Adding the new URL is unnecessary, a simple Redirect or the rewrites in the provided .htaccess takes care of redirecting any requests to the new URL.
The only thing I had to add was a Redirect from /remote.php/carddav/addressbooks/ to /remote.php/carddav/addressbooks/users/ to get CardDAV working again in Thunderbird with SOGo connector.
Does also work fine in DAVdroid on Android. Strange thing is that 'preemptive authentication' (which is basically sending Basic Auth in every request) does not work for Resource Detection, but must be re-enabled later to get contacts sync working. Any ideas on that?
PS: What's the new URL for the contact_birthdays calendar? Resource detection in DAVdroid doesn't find it and it's the only item for which the rewrite does not have any use.
This works for me, too on all but one computer but I guess that's a different issue which I have to look into. It would be really nice if owncloud uses the login names everywhere. This might need a migration process for the update.
Edit: I think it's not working for some because of the missing redirects.
What are the steps needed to apply the @blizzz patch? I've edited ./apps/dav/lib/connector/sabre/auth.php to add the '+' lines from #23480 (backport to 9.0 I guess?), and remove the '-' lines, as well as restarted apache, but not seeing any difference. Perhaps I've missed something?
That's all I did. Then restarted apache.
I'm closing this because the fix is merged with #23404 and #23480
Hi, check out groups and group_user with gid containing slashes. This was my error.
I had a group named "CO/GH". Calender gave a 404 "principal CO not found"...
i renamed the group in groups and groups_users "GH CO" ... and running :)
@Scherar: Thanks a lot. Your solution made our calendar working again. Removed the "/" of a group name in the database tables "groups" and "group_users".
After reading other issues with calendar in OC9, I also modified the table "oc_dav_shares". Changed the field "principaluri" to "principals/groups/[groupname]" if followed by a groupname. It was "principals/users/[groupname]" before.
Note to self: Don´t allow business colleagues to do user management. The first group they created had "&" and "/". _argh_
This helped me too, but it is definitely a bug. Either dont let anyone insert / or &, or handle it. I would vote for the second one!
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.