[Bug]: Public Share Link fails when link creator has access via groupfolder and share

⚠️ 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

When a user has a folder/file Shared to him and is then added to the Groupfolder, the file is located in, he can not Share this file successfully

We encounter this issue quite often, as users share groupfolder-content to give quick access to a new member.
When this member is then added to the groupfolder, the still existing Share Link is limiting correct workflow.

Steps to reproduce

1. Create a Groupfolder, give access only to user A
2. Have User A create a file "file" in the groupfolder
3. Share file from User A to User B (do not allow further sharing)
4. Add User B to the Groupfolder, make sure he is allowed to share
5. As User B: Create a Share Link on "file"
6. Test Share Link in private/incognito Tab/Browser. it will show "Page not found"

Can be fixed by editing the Share to User B (allow sharing) or deleting the Share completely

Expected behavior

Being a member of the groupfolder should overide the limits of the share, or delete the Share completely

Nextcloud Server version

31

Operating system

None

PHP engine version

None

Web server

None

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

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

Reproduce the failure using the six listed groupfolder and sharing steps, then trace the public share-link permission handling for a user who has both a direct share and groupfolder access. Verify the behavior in a private or incognito browser. Done means User B's public link opens successfully after groupfolder access is granted, without requiring the existing share to be edited or deleted.