-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repair step for invalid oc_share.uid_owner values #28503
Comments
I think I've got a query that should make it possible to find the mismatched share entries, the ones where the "oc_share.uid_owner" does not match the storage owner as represented in oc_mounts: select s.id,s.share_type, s.stime, s.uid_owner, s.uid_initiator, s.share_with, s.file_source, s.file_target, m.storage_id, m.user_id, m.mount_point from oc_share s, oc_filecache f, oc_mounts m where s.file_source=f.fileid and f.storage=m.storage_id and concat('/', m.user_id, '/')=m.mount_point and s.uid_owner != m.user_id |
then for each entry, the repair step must update the share owner to match the one from the mounts and if the uid_initiator is equal to the owner, also change it not sure yet what to do in other cases, not sure what happens if the uid_initiator is for a share where the owner doesn't have access any more |
and make sure to tweak the query so it can run faster... it seems to be slow on bigger envs |
or alternatively make this a separate occ command so it doesn't run on upgrade with the other repair steps |
|
PR here: #32211 |
Steps
select * from oc_share where share_type=0 and share_with='user2'
and take note of the share idupdate oc_share set uid_owner='user3' where id=$id
, replace $id with the id from the previous queryExpected result
Contents of "test" visible.
Actual result
Folder "test" appears empty.
Versions
The behavior was observed on Nextcloud 20.0.8.
But I was able to reproduce it on master 3ac9b56
Analysis
Please note that this situation has been reported following a transfer ownership operation that failed in some way, and left the oc_share table in the state created above.
Because the "uid_owner" does not match the actual owner of the storage to which the "item_source" points, it seems the code decides to return no data.
Solutions
Make the code that creates the "supershare" more robust and tolerate wrong "uid_owner" values, but is that safe ? This should probably also log a warning of sorts, but without polluting the logs.
Write a repair step that finds such scenarios and updates "uid_owner" to the correct value based on who the original storage owner is.
The text was updated successfully, but these errors were encountered: