Repository navigation
Repair step for invalid oc_share.uid_owner values #28503
Description
Activity
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
-
⚠️ beware of group folders and system-wide ext storages where no storage owner exists, need to exclude those somehow
-
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.