Public link shares can be rebound to the wrong node during ownership transfer

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Public link shares can be rebound to the wrong node during ownership transfer when the shared item is on a mounted path (notably Groupfolders/Teamfolders) and destination user mount visibility differs.

In my case, after transferring with occ files:transfer-ownership --move OLD_ID NEW_ID, an existing public link originally created on a Groupfolder still worked but now pointed to the destination user's /files root, exposing all data accessible there via that token.

Code analysis at current server HEAD (045a41625a5) shows restoreShares() updates share owner fields before node resolution. Because Share::getNode() resolves by shareOwner scope, mounted shares can resolve in the wrong user scope and persist an unintended file_source.

This happens especially in the case of moving data from a backend user with attached groups to a new OIDC user which did not provide the groups yet.

Steps to reproduce

1. Install Nextcloud with Groupfolders (Teamfolders) enabled. Ensure two users exist: OLD_ID (source) and NEW_ID (destination).
2. Give OLD_ID access to a Groupfolder and create a public link share to a folder/file inside that Groupfolder.
3. Ensure NEW_ID exists but has not completed first login / role-group sync (OIDC-backed user is a likely trigger). In practice this means destination mount visibility may differ from source.
4. Run ownership transfer with move: occ files:transfer-ownership --move OLD_ID NEW_ID.
5. Open the existing public link token.
6. Observe link target is no longer the original Groupfolder node; in the reported case it pointed to destination /files root.

Expected behavior

Ownership transfer must never broaden a link-share scope.

If the exact original share node cannot be resolved safely during transfer, behavior should fail closed:

• keep original file_source unchanged for that share, or
• disable/delete the affected link share and log a clear warning/error.

It should not best-effort remap to a broader parent or root location.

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.3

Web server

Nginx

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

Can be shared privately.

List of activated Apps

Can be shared privately.

Nextcloud Signing status

"No errors have been found"

Nextcloud Logs

Can be shared privately.

Additional info

No response

Start by tracing ownership-transfer handling through restoreShares() and Share::getNode(), then reproduce with a mounted Groupfolder path whose visibility differs between OLD_ID and NEW_ID. Done means an existing public link cannot resolve to a broader or wrong node after occ files:transfer-ownership --move; verify the affected share is preserved safely or disabled with a clear warning.