Resharing via Link appears to be broken after Update to 7.0.3

[viasys]

Steps to reproduce

1.Share a File that has been shared with you via link
2. Try to Open the Link

Expected behaviour

Link should open the Download Page for the shared file

Actual behaviour

Link leads to a error message saying this link does not exist

Server configuration

Operating system:

Debian 7

Web server:

Apache2

Database:

MariaDB 10.0

PHP version:

5.4.35

ownCloud version:

7.0.3

Updated from an older ownCloud or fresh install:

Updated from 7.0.2

List of activated apps:

Activity, Delete Files, Documents, First Run Wizard, Full Text Search, PDF Viewer, Share Files, Text Editor, Updater, Files Move

Are you using external storage, if yes which one:

No

Are you using encryption:

No

Client configuration

Browser:

Firefox

Operating system:

Windows 7

Web server error log

Nothing

ownCloud log (data/owncloud.log)

{"reqId":"547739393b36c","app":"share","message":"could not resolve linkItem","level":0,"time":"2014-11-27T14:46:17+00:00","method":"GET","url":"/public.php?service=files&t=

If that Helps: I'm forcing the use of a Password and expiry Date for Link sharing.

I hope that has not been reported yet.

[LukasReschke]

{"reqId":"547739393b36c","app":"share","message":"could not resolve linkItem","level":0,"time":"2014-11-27T14:46:17+00:00","method":"GET","url":"/public.php?service=files&t=

Can the share still be found in the DB in the "oc_share" table?

[viasys]

Yes

[GreenArchon]

A small "maybe me too"
This seems to occur to me for any file that is inside a folder that was shared to me with the share function directly (not from a link). However, I can re-share with a valid link the folder itself.

ie.: As part of membership in a group, I'm shared the folder "Folder A". I can create a valid link to "Folder A", but not to any file or folder inside that folder.

However, the owner of the share can generate valid link from these shares (and they both create 2 different links). Here's both entries in the oc_cache table. The second one is from the owner and works:

(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)
(1655, 3, NULL, 'frederic.fortier', NULL, 'file', '425060', '/425060', 425060, '/cc1101.pdf', 1, 1417227458, 0, '2014-12-29 00:00:00', 'cb187e7def9a600fd2dae67695f74f2f', 0)
(1656, 3, NULL, 'oronos.polytechnique', NULL, 'file', '425060', '/425060', 425060, '/cc1101.pdf', 1, 1417227511, 0, '2014-12-29 00:00:00', 'fc14e015b352fac7493cc0b5a47f44d8', 0)

[LukasReschke]

@schiesbn @icewind1991 Ideas?

[arielvb]

I've the same behaviour as @GreenArchon

1. First user user1 shares a folder to an owncloud group group1
2. An other user from the group1 shares a file of the folder using the share link.

But if user1 (the owner of the folder) shares the same file with the share link it works.

[jbonor]

Me too, upgraded from 7.0.2 to 7.0.3 and 7.0.4 and I can no longer share files with links from folders shared with me. Anyone have a solution?

[a-schild]

We see the same problem here in 7.0.4 (Worked some versions past (6.x?))
We see this message in the server log file:

{"reqId":"54aaac69c1905","app":"share","message":"could not resolve linkItem","level":0,"time":"2015-01-05T15:23:21+00:00","method":"GET","url":"/public.php?service=files&t=11a2866bada7d831a25cccfdc7202b60"}

[viasys]

For me it was working in 7.0.2.

[Do-D]

Just saw that thread, I think the same Issue as this: #12802
As mentioned I noticed that the link I see under the section "Shared by Link" when I reshare a file is not working either.

[a-schild]

Not sure it's the same as #12802, since here we share via token (t=xxxxxxxxx) and in the other issue it is shared in another way.
But perhaps related somewhere deeper in the code base.

Probably due to the code refactoring done here with this commit: 988c85d

[GreenArchon]

Pretty sure it isn't 988c85d since it isn't in owncloud 7.0.3/7.0.4 ;)

Wherever the bug is, it was introduced between 7.0.2 and 7.0.3

[LukasReschke]

Yup. That refactoring is only in master (aka up-coming 8.0)

If some of you feel advantageous and want to have it sooner resolved I can highly recommend doing a small git bisect crash-course.
With git bisect you can find out which commit introduced the broken behaviour, for that you just need to know a commit where it last worked and step by step you will rush through the commits and try to find the bad one. A somewhat more verbose description can be found at http://webchick.net/node/99

(otherwise you might need to wait once the responsible persons are back from holiday and have time etc… - usual story ;-))

[GreenArchon]

Alright, it's a bit trickier than anticipated. ;)

Basically, if you group share a folder in version >= 7.0.3 and someone makes a link in a sub-folder, it will work as expected (which might explain how this passed testing).

However, if you group share a folder in version <= 7.0.2 and then upgrade to version >= 7.0.3, the share links of subfolders won't work.

Looking at oc_share in the database, I can see that folders created in version <= 7.0.2 have one entry per group. However, folders created after 7.0.2 have an entry per group and per person in each group (with the parent column referring to the group entry), probably because of #10107 to allow for cumulative permissions if the folder is shared to more than one group.

I didn't look at the code directly (having to look at both stable7 and the refactored version in master when I'm not familiar with the project turned me off...), but the permission verification step in a shared link probably checks for the user permission only, and not the corresponding groups anymore (since it's what it should be expecting from a folder created at version >= 7.0.3).

Possible solutions would be to fall back to group checking if the user isn't there or have an upgrade script to add the users of the group in each group share of the db, thus having consistency in group shares between versions.

[a-schild]

Adding the missing rights/entries in the upgrade script sounds far better than leaving "old" behaviour code in the system.
Such old behaviours are difficult to test and a problem at each refactoring

[viasys]

Is there any Update on this Topic? Or do you maybe need any further information?

[LukasReschke]

@PVince81 Could that also be #13361? – What are the easiest step to verify this?

[PVince81]

@viasys do you still have the token from the public link ?
You can check the database with:
select * from oc_share where token='thetokenfromthepubliclink'.

If you say it was a reshare, then the "parent" column should have a value.
If it has none, then the share is broken, possibly similar to #13361.

If the "parent" column has a value, check the parent share:
select * from oc_share where id=XXX replace XXX with the parent id you got from the previous query.

[viasys]

@PVince81 I dont have the old link or token anymore, would it also work with a new link?

[PVince81]

Yes, as long as that new link is also broken.

You said it is a reshare. Can you describe the sharing situation a bit more ?
Did your user get the file/folder through a group share or a single user share ?

Did you rename the file/folder before resharing ?

[viasys]

The Szenario is the following:

The User is in a Group and he has a Folder shared with the Group, he now tries to share a file from within that shared folder via a link, the Folder or the File was not renamed, I will try to get a broken Link again.

[PVince81]

That sounds very close to the scenario from #13361, likely related. The database results will help confirm this.

If you know the name of the folder, you could also try this:
select * from oc_share where file_target like '%thefoldername%';

This will show the group share and also the reshare. We need to check if the parent-child relationship is broken.

[viasys]

The Parent Value is NULL for the first SQL Query, I'm not sure if I understood the second Query correct: I went into the Folder that was shared with me called FOLDER1 and shared a file from within that Folder with a Link. Now I execute
select * from oc_share where file_target like '%FOLDER1%' ;
which gives me no Result

[PVince81]

Yes this is correct. Does the forlder name have spaces ? Maybe try with just parts of it, for example '%FOLD%'.

The missing parent value sounds exactly like the case described in #13361.

There is a workaround for this: as your user, rename FOLDER1 to FOLDER1X then rename it back to FOLDER1. Then delete the link share and recreate it.

[viasys]

Yes it indeed had spaces within the Name, I got some results now, but my shared link was not in it.

[PVince81]

Do you mind posting the results of that query ?
You can replace the user names / file names with dummy ones.

If not we can try with finer grainer queries.

What we should see:

• 1 storage entry with share_type 1 (the group share) that shares with the correct group name
• a few additional entries, one for each user in the group, including you, with parent id pointing to that first entry.

I suspect that the additional entries are missing, or maybe your user doesn't have that entry. (like in the linked ticket)

[viasys]

I only got 1 result for that specific folder which is the entry with share_type 1, where it is shared with my group

[viasys]

I have to get going now, if you have any further Questions, I will answer them later tonight/tomorrow.

[viasys]

@PVince81 I will try the workaround later, I dont have the option "Restrict users to only share in their groups", but I do have the restriction to force password and expiry date. And I'm very sure it worked before 7.0.3 if that helps, because we were using this function pretty often.

[PVince81]

That's fine.
The workaround should be able to fix the issue for you guys until we can come up with a proper fix.

I managed to nail down the steps to recreate this exact situation: #13361 (comment)

[GreenArchon]

@PVince81 your workaround is great, however by doing it on a folder that was shared to multiple groups I was part of (3 of them in the present case) it is now shared with me 3 times (and I suspect with different permissions herited from different groups, but this is only speculation).

Just something to keep in mind when doing your fix.

Edit: Here's the resulting database entry:

select id, share_type, share_with, uid_owner, parent, item_source, permissions, stime from oc_share where file_target = '/Avionics';
+------+------------+------------------+----------------------+--------+-------------+-------------+------------+
| id   | share_type | share_with       | uid_owner            | parent | item_source | permissions | stime      |
+------+------------+------------------+----------------------+--------+-------------+-------------+------------+
|  359 |          1 | Avionique        | oronos.polytechnique |   NULL | 65576       |          31 | 1412734061 |
|  740 |          1 | Oronos Trusted   | oronos.polytechnique |   NULL | 65576       |           1 | 1413150630 |
| 1674 |          1 | admin            | oronos.polytechnique |   NULL | 65576       |          31 | 1420572037 |
| 1817 |          2 | frederic.fortier | oronos.polytechnique |    359 | 65576       |          31 | 1412734061 |
| 1818 |          2 | frederic.fortier | oronos.polytechnique |    740 | 65576       |           1 | 1413150630 |
| 1819 |          2 | frederic.fortier | oronos.polytechnique |   1674 | 65576       |          31 | 1420572037 |
+------+------------+------------------+----------------------+--------+-------------+-------------+------------+

[PVince81]

@GreenArchon did you upgrade to 7.0.4 yet ? It should solve the multiple group shares issues if I remember well.

[GreenArchon]

@PVince81 yes, this is on 7.0.4

[PVince81]

@schiesbn were there any cases left of grouping that would still cause the recipient to receive folders multiple times ?

[a-schild]

Here my diagnosis of our case:

The initial share with problems had been created in 6.x

User "xxx-admin" did share the folder /PR-Share with group "pr", with "can share" and "can edit" permissions

||id |share_type|share_with|uid_owner |parent|item_type|item_source|item_target|file_source|file_target     |permissions
| 52 |  1       |pr        |admin|      |folder   |37730      |/37730     |37730      |/Shared/PR-Share|31

The user felix (member of the "pr" group) did then reshared a file inside a subfolder of the shared folder via public link.

From the user felix point of view, then file has this URL:
/Shared/PR-Share/Pressefotos/Spring_1-2015/Spring_1-2015_hoch_11.jpg

This token is then invalid when accessed from the webbrowser

||id |share_type|share_with|uid_owner |parent|item_type|item_source|item_target|file_source|file_target               |permissions|token
|220 |3         |          |felix     |      |file     |96609      |/96609     |96609      |/Spring_1-2015_hoch_11.jpg|1          |46d7f1d53a1c3292f575246d0a6a2b01

I see that the parent entry for the final token-share is NULL, when setting it to 52,
it then works.
But also new shared created with 7.0.4 for files in the same folder have parent=NULL

[PVince81]

@a-schild thanks for the info. This is indeed exactly the same bug.

You can try the workaround for now: as "felix", rename "PR-Share" to "PR-Share-test" then back again to "PR-Share". This should "repair" the group share in a way that will make future resharing work again.
You'll need to recreate the reshares that had parent=null

[PVince81]

Let's wait for @viasys to give feedback, then this can be closed as duplicate of #13361 (comment) which contains more detailed steps on how to recreate the situation from scratch.

As for @GreenArchon's multiple grouping case, we might want to make a separate ticket for that.

[a-schild]

@PVince81 renaming the share did not help fixing the existing tokens with parent=null, but now at leat new shares from the same folder are working correctly.

In the database the renaming of the PR-Share did insert this record, but did not touch "child" entries

||id |share_type|share_with|uid_owner |parent|item_type|item_source|item_target|file_source|file_target               |permissions
|222 |2         |          |felix     |      |folder   |37730    |/37730       |37730      |    /Shared/PR-Share|1          

[PVince81]

Yes, that's what I meant. It will only fix the group share itself, not the reshares.
So the new reshares are properly based off the group share.

Note that there is no way to auto-fix the broken reshares since there is no way to automatically and accurately find out what the missing parent would have been.

[PVince81]

And... here it is: https://github.com/owncloud/core/blob/stable7/lib/private/share/share.php#L343

When the user has more than one group, the string concatenation will make the query fail to find results.
Because (?) is then replaced by ('g1,g2') instead of ('g1', 'g2')

[PVince81]

Fix is here: #13423

There is a slight chance that the fix will also fix @GreenArchon's issue, but I'm not sure whether the group shared need to be manually re-created for the folder grouping to work.

The issue itself appears in the following situation:

1. the share is a reshare
2. the use to whom it is reshared has more than one group assigned

and possibly many other cases where a user has more than one group...

[GreenArchon]

@PVince81 Thanks for the fix, I can confirm it makes links work again.

It doesn't resolve my issue with the multiple entries when on multiple groups. If you think it'd be wiser to open another issue I can do it, but otherwise I can live with the bug, since shares created at version >= 7.0.3 don't have this behaviour.

[LukasReschke]

If you think it'd be wiser to open another issue I can do it, but otherwise I can live with the bug, since shares created at version >= 7.0.3 don't have this behaviour.

Please create a new issues for that. If you experience this issue others might as well and they might not be able to live with this limitation.

Thanks for testing the patch!

[GreenArchon]

No problem. Issue created at #13429

[PVince81]

@karlitschek @DeepDiver1975 tagging this bug as showstopper as it breaks reshares, a fix is already there to review: #13423

[viasys]

@PVince81 Sorry it took so long but i tested your Workaround and it worked, thanks for working that out with me and I'm looking forward for the fix!