Update error when duplicate sub-shares exist

[lukovas]

There was an error updating. Please, help!

OC\Share20\Exception\ProviderException: Parent of share should be unique

Detailed logs:

Preparing update
Set log level to debug
Turned on maintenance mode
Updating database schema
Updated database
Updated "activity" to 2.3.4
[1 / 28]: Drop old database table: calendar_calendars
[2 / 28]: Drop old database table: calendar_objects
[3 / 28]: Drop old database table: calendar_share_calendar
[4 / 28]: Drop old database table: calendar_share_event
[5 / 28]: Drop old database table: file_map
[6 / 28]: Drop old database table: foldersize
[7 / 28]: Drop old database table: fscache
[8 / 28]: Drop old database table: gallery_sharing
[9 / 28]: Drop old database table: locks
[10 / 28]: Drop old database table: log
[11 / 28]: Drop old database table: media_albums
[12 / 28]: Drop old database table: media_artists
[13 / 28]: Drop old database table: media_sessions
[14 / 28]: Drop old database table: media_songs
[15 / 28]: Drop old database table: media_users
[16 / 28]: Drop old database table: permissions
[17 / 28]: Drop old database table: pictures_images_cache
[18 / 28]: Drop old database table: principalgroups
[19 / 28]: Drop old database table: principals
[20 / 28]: Drop old database table: queuedtasks
[21 / 28]: Drop old database table: sharing
[22 / 28]: Drop old database table: clndr_calendars
[23 / 28]: Drop old database table: clndr_objects
[24 / 28]: Drop old database table: clndr_share_event
[25 / 28]: Drop old database table: clndr_share_calendar
[26 / 28]: Drop old database table: clndr_repeat
[27 / 28]: Drop old database table: contacts_addressbooks
[28 / 28]: Drop old database table: contacts_cards
[28 / 28]: Drop old database tables
[1 / 4]: Remove old (< 9.0) calendar/contact shares
[2 / 4]: Remove old (< 9.0) calendar/contact shares
[3 / 4]: Remove old (< 9.0) calendar/contact shares
[4 / 4]: Remove old (< 9.0) calendar/contact shares
[4 / 4]: Remove old (< 9.0) calendar/contact shares
[1 / 2]: Fix permissions so avatars can be stored again
[1 / 1]: Fix permissions so avatars can be stored again
[1 / 44]: Move user avatars outside the homes to the new location
[2 / 44]: Move user avatars outside the homes to the new location
[3 / 44]: Move user avatars outside the homes to the new location
OC\Share20\Exception\ProviderException: Parent of share should be unique

[PVince81]

Seems some of your shares are in an inconsistent state.

I suggest you check select * from oc_share where share_type=2 order by id.
These are sub-entries for each recipients. The parent share is the one where the "parent" column points to the parent share id. (select * from oc_share where id=$parent, replace $parent with the value from the column)

In your database, for some unknown reason, one of these sub-entries isn't pointing to the same parent like the others. Normally they all point to the same parent when it's the same share.

If you manage to find the matching broken share, please post the select result here so we can examine it (and tell you how to manually fix it)

[lars-sh]

I ran into just the same problem and checked the database based on your information. All seemed to be just fine, so I checked the exception in owncloud.log and finally the code. It seems there's an obvious mistake while performing "Ensure uniquenes of parents".

[88fingerslukee]

I'm having a very similar issue except that the update succeeded. The problem is that two of my users (the only ones who actually have shared anything) cannot login due these errors. Here is the select result as asked:
owncloud issue.txt

What do I do?

[lars-sh]

May you verify if https://github.com/owncloud/core/pull/28080/files helps?

[88fingerslukee]

Yes, that did work! It allowed me to sign in but another user was still having trouble. I had to reset that user and now everything is good.

[PVince81]

From my understanding of that code is that it was designed to throw an exception if a subshare has more than one parent, which should never happen and means the data structure in the DB is corrupted (maybe through a bug).

On the other hand, failing hard like this isn't user friendly so maybe your fix is alright but would need to at least log something, maybe a warning, so that an administrator can spot that there is something wrong with the data structure.

[lars-sh]

@PVince81 that's absolutely right, though I'm not an ownCloud developer nor aware of its Framework, so that's just a first fix.

[ahmedatawfik]

Hi Guys,
I think I am having the same issue after upgrading from 9.0.11 to 10.0.4

This is the error I receive when running occ scan:

https://gist.github.com/socrat3000/e9ada76a85c03d6f8f0637c141d43106

and when I run the query by @PVince81 , I get the following result:

https://gist.github.com/socrat3000/94682f120b485a8466872ef378b9e172

Any ideas how I can fix this?

[ahmedatawfik]

And this fix: https://github.com/owncloud/core/pull/28080/files is already there, but not resolving the issue.

[PVince81]

@socrat3000 I don't see anything wrong with the result yet. Can you also do a select * from oc_share where id=(...) and put all the parents from the last result in there ?

[ahmedatawfik]

There you go:

https://gist.github.com/socrat3000/3b461b5616ea12e5ce4bff9346559f72

[ahmedatawfik]

By the way, the account with the problem is 8D0D8BA8-DF3B-44FC-BEEA-25C605E57F88

[PVince81]

Ok I see, so this user has two sub-entries instead of one. You could simply delete the oc_share entry with id 334.

I'll reopen this ticket so we can provide a repair step that detects this scenario and automatically deletes duplicates.

[ahmedatawfik]

334? I don't get it

[PVince81]

| 333 |          2 | 8D0D8BA8-DF3B-44FC-BEEA-25C605E57F88 | 835D426E-3E43-43FA-AE3C-BF79CBC65AB2 |    332 | folder    | 69188       | NULL        |       69188 | /Templates (2)                                        |          31 | 1506601448 |        0 | NULL       | NULL  |         0 | NULL          | NULL       |
| 334 |          2 | 8D0D8BA8-DF3B-44FC-BEEA-25C605E57F88 | 835D426E-3E43-43FA-AE3C-BF79CBC65AB2 |    332 | folder    | 69188       | NULL        |       69188 | /Templates (2)                                        |          31 | 1506601448 |        0 | NULL       | NULL  |         0 | NULL          | NULL       |

These two rows are identical except for the share id. This is the problem, so delete the second one with id 334.

[ahmedatawfik]

ah I get it.

So, you mean I should run this statement?

delete from oc_share where id=334

[PVince81]

Yes.

Now the reason why you have duplicates remains a mystery and is likely not reproducible easily.
Possible cause could be a race condition where two code paths inserted the same entry from two different places at the same time. I'd expect the DB transaction to prevent that though.

[ahmedatawfik]

It's now working, thanks a lot.

Will ask the user to try to login again, because this issue was preventing him from logging in.

Will update you with the result.

[ghost]

Returns this:

MariaDB [owncloud]> select parent, count(*) from oc_share where share_type=2 group by parent, share_with having count(*) > 1;
+--------+----------+
| parent | count(*) |
+--------+----------+
|   4887 |        2 |
|   5450 |        3 |
|   6726 |        2 |
|   6969 |        2 |
|   7126 |        2 |
|   7297 |        2 |
|   7297 |        2 |
+--------+----------+
7 rows in set (0.00 sec)

I should then run sth like this? (note oc_share, not oc_shareS) This gives me:

MariaDB [owncloud]> select * from oc_share where parent=4887 order by share_with;
+------+------------+------------+-----------+--------+-----------+-------------+----------------+-------------+----------------------------------------+-------------+------------+----------+------------+-------+-----------+---------------+------------+
| id   | share_type | share_with | uid_owner | parent | item_type | item_source | item_target    | file_source | file_target                            | permissions | stime      | accepted | expiration | token | mail_send | uid_initiator | share_name |
+------+------------+------------+-----------+--------+-----------+-------------+----------------+-------------+----------------------------------------+-------------+------------+----------+------------+-------+-----------+---------------+------------+
| 5563 |          2 | Oudjtiov   | MrFoobar |   4887 | file      | 204168      | /Shared/204168 |      204168 | /Shared/Kidoxmatik und Dutimik (2).pptx |          19 | 1478250020 |        0 | NULL       | NULL  |         0 | NULL          | NULL       |
| 6452 |          2 | Adfsafsaff | MrFoobar |   4887 | file      | 204168      | NULL           |      204168 | /Shared/Kidoxmatik und Dutimik (2).pptx |          19 | 1478250020 |        0 | NULL       | NULL  |         0 | MrFoobar     | NULL       |
| 6424 |          2 | Kudutiisdf | MrFoobar |   4887 | file      | 204168      | NULL           |      204168 | /Shared/Kidoxmatik und Dutimik (2).pptx |          19 | 1478250020 |        0 | NULL       | NULL  |         0 | MrFoobar     | NULL       |
| 6429 |          2 | Kditpx     | MrFoobar |   4887 | file      | 204168      | NULL           |      204168 | /Kidoxmatik und Dutimik (2).pptx        |          19 | 1478250020 |        0 | NULL       | NULL  |         0 | MrFoobar     | NULL       |
| 5562 |          2 | Kdut       | MrFoobar |   4887 | file      | 204168      | /Shared/204168 |      204168 | /Shared/Kidoxmatik und Dutimik (2).pptx |          19 | 1478250020 |        0 | NULL       | NULL  |         0 | NULL          | NULL       |
| 5560 |          2 | Blafo      | MrFoobar |   4887 | file      | 204168      | /Shared/204168 |      204168 | /Shared/Kidoxmatik und Dutimik (2).pptx |          19 | 1478250020 |        0 | NULL       | NULL  |         0 | NULL          | NULL       |
| 5561 |          2 | Blafo      | MrFoobar |   4887 | file      | 204168      | /Shared/204168 |      204168 | /Shared/Kidoxmatik und Dutimik (2).pptx |          19 | 1478250020 |        0 | NULL       | NULL  |         0 | NULL          | NULL       |
| 6498 |          2 | Fooba      | MrFoobar |   4887 | file      | 204168      | NULL           |      204168 | /Shared/Kidoxmatik und Dutimik (2).pptx |          19 | 1478250020 |        0 | NULL       | NULL  |         0 | MrFoobar     | NULL       |
+------+------------+------------+-----------+--------+-----------+-------------+----------------+-------------+----------------------------------------+-------------+------------+----------+------------+-------+-----------+---------------+------------+
8 rows in set (0.00 sec)

Thanks a lot again for your fast replies @PVince81 !! :) 👍

[PVince81]

Yes. See how the last result has "Blafo" twice. Delete one of both entries.

You'll need to repeat the process for every of the 7 results above. This is to get you unstuck.

Now seeing that more and more people are having this problem, I think we should work on writing a repair step that will clean this up before an upgrade.

[ghost]

So sth like this for my example?

DELETE FROM oc_share WHERE id='5561';

[PVince81]

@p-thurner yes. Make sure you have a backup of the database first.

[ghost]

@PVince81 thanks again! :) That did the trick. I can now run a

www-data@cloud:~/owncloud$ php occ maintenance:repair
www-data@cloud:~/owncloud$ php occ upgrade
www-data@cloud:~/owncloud$ php occ maintenance:repair
www-data@cloud:~/owncloud$ php occ maintenance:mode --off

And the WebUI / everything else is working again. Thumbs up for good support from the developers :) 🥇

[PVince81]

Thanks for confirming!

[felixboehm]

Thanks @PVince81 for rising priority.

[PVince81]

Steps to reproduce manually and also illustrate the sub-share feature:

1. Create three users user1, user2, user3
2. Add all three to a group "group1"
3. Login as admin
4. Create a folder "test"
5. Share "test" with "group1"
6. Login as "user1"
7. Delete the received "test" (unshare from self)
8. Login as "user2"
9. Rename "test" to "test_mine"
10. Login as "user3"
11. Rename "test" to "test_mine"
12. Look at oc_share contents: you should see one main share to "group1" and three subshares: user1 has a subshare with permission 0 (opted-out), and both user2 and user3 have a subshare with the target folder.
13. Now rename "user3" to "user2" in the subshare entry's "share_with" column. This will make the third subshare a duplicate of the one from "user2"
14. Try listing the files over web UI or Webdav

You'll get an entry in the log with "OC\Share20\Exception\ProviderException: Parent of share should be unique".

To fix this, the goal is to implement a repair step that will select such entries. See #27990 (comment) for some query ideas, beware as they might be expensive. Then if duplicates were found, delete them and keep the entry with the smallest share id from the duplicates.

Add a unit test that inserts such entries, runs the repair step, then checks that the duplicates are gone.

@sharidas let me know if you have further questions

[PVince81]

repair step implemented, closing

[lock]

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.