Skip to content

Moving share in/out of another one doesn't update uid_owner in some cases聽#30791

Description

@PVince81

How to use GitHub

  • Please use the 馃憤 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Steps to reproduce

  1. Login as admin
  2. Create three users "Alice", "Bob" and "Charles"
  3. Put them into a group "named users"
  4. Create a common folder "/common"
  5. Share "/common" with the group "named users" (in this case "admin" is the share owner)
  6. Login as "Alice"

Scenario 1: move in folder where a share exists in a sub-dir

  1. Create a folder "movingin/subshare"
  2. Share "subshare" with "Bob" (in this case the share owner is "alice")
  3. Move "movingin" into "/common"
  4. select * from oc_share where file_target like '%subshare%' => 馃挜 uid_owner should be "admin" instead of "alice"

Scenario 2: move out a folder

  1. Create a folder "/common/movingout"
  2. Share "movingout" with "Bob" (in this case the share owner is "admin" since it's in the common folder)
  3. Move "/common/movingout" to "/"
  4. select * from oc_share where file_target like '%movingout%' => 馃挜 uid_owner should be "alice instead of "admin"

Scenario 3: move out a folder with a subshare

Same as scenario 2 but the share is on "/common/movingout/subshare".

Expected behaviour

uid_owner is always correctly adjusted

Actual behaviour

uid_owner stays on the previous value

Server configuration

Database: MariaDB 10.6.5

PHP version: 7.4.27

Nextcloud version: 23.0.0

Updated from an older Nextcloud/ownCloud or fresh install: fresh install

Where did you install Nextcloud from: git v23.0.0

Logs

Nextcloud log (data/nextcloud.log)

No log entries for both scenarios.

To dos

  • check if issue exists in other major releases
    • v22.2.3: yes
    • v21.0.7
    • v20.0.14
    • v23 last RC
    • stable18: yes
  • bisect? might be too old
  • update integration tests to also include a share owner check for all the moving scenarios
  • fix the bug
    • also test with group folders
    • also test with system-wide ext storage
    • also test with personal ext storage
  • provide repair step / occ command, see Repair step for invalid oc_share.uid_owner values聽#28503

Activity

  1. PVince81 commented on Jan 21, 2022

    @PVince81
    MemberAuthor

    Interestingly, the transfer ownership will skip those bogus entries.

    Steps

    1. Run scenario 2
    2. occ files:transfer-ownership alice charles
    3. select * from oc_share where file_target like '%movingout%'

    The share did not get transferred and the command says that the share with that id points at a non-existing file (which is a wrong error message) and skips it, so the share stays broken in some way.

  2. added this to the Nextcloud 24 milestone on Jan 21, 2022
  3. icewind1991 commented on Feb 2, 2022

    @icewind1991
    Member

    Do you know if this has ever worked, I don't remember there being any logic to handle this.

    I guess the only real way to handle this is listen for all move events, if the owner of the source and target match, find all shares in the moved folder and update them, which wouldn't exactly be cheap to do with a large number of shares

  4. PVince81 commented on Mar 24, 2022

    @PVince81
    MemberAuthor

    Do you know if this has ever worked, I don't remember there being any logic to handle this.

    I guess the only real way to handle this is listen for all move events, if the owner of the source and target match, find all shares in the moved folder and update them, which wouldn't exactly be cheap to do with a large number of shares

    I'm not sure. Maybe it always flew under the radar since currently only transfer ownership seems to reveal the issue.

    We also noted in some case that fileid resolution can fail also in such scenarios, see #31695

  5. PVince81 commented on Mar 28, 2022

    @PVince81
    MemberAuthor

    I've managed to fix the issue: #31728

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions