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

[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

0. Login as admin
1. Create three users "Alice", "Bob" and "Charles"
2. Put them into a group "named users"
3. Create a common folder "/common"
4. Share "/common" with the group "named users" (in this case "admin" is the share owner)
5. 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

[PVince81]

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.

[icewind1991]

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

[PVince81]

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

[PVince81]

I've managed to fix the issue: #31728