[Bug]: Recipients can no longer see or copy existing public link shares (regression from #65258) #65935

⚠️ This issue respects the following points: ⚠️

• This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
• This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
• I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
• I agree to follow Nextcloud's Code of Conduct.
• I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.

Bug description

Description

A user who received a share with full permissions (including reshare) can still see in the sharing sidebar that a public link exists on the folder, but the "Copy link" button is no longer displayed.

The OCS API returns the link share with token: null and url: null to anyone who is not the file owner or the share initiator.

Impact

This breaks a common workflow: people working in a shared folder used to copy the existing public link. They now have to create additional links, which multiplies the links to manage.

Root cause

PR #65258 ("fix: use correct node when formatting share token", backported in #65259–#65264) changed the token condition in ShareAPIController::formatShare():

- $token = $userHasEnoughPermissions ? $share->getToken() : null;
+ $token = $userHasEnoughPermissions && $this->canEditShare($share) ? $share->getToken() : null;

The PR description only mentions replacing a possibly null $recipientNode with $node. The added canEditShare() check is not mentioned, yet it changes behaviour significantly:

• canEditShare() only returns true for the file owner, the share initiator, or ownerless mounts (team folders).
• The existing permission check, which redacts the token when the link grants more permissions than the current user has, already covers the risk of a recipient escalating their permissions through a link.

Steps to reproduce

1. User A creates a folder and a read-only public link share on it.
2. User A shares the same folder with user B with all permissions (including reshare).
3. User B opens the folder's sharing sidebar.
4. The existing public link is listed, but there is no "Copy link" button.

The API call confirms the redaction:

GET /ocs/v2.php/apps/files_sharing/api/v1/shares?path=/folder&reshares=true

returns the link share with token: null and url: null.

Expected behavior

• If this restriction is intentional: could it be documented (changelog, admin manual) and ideally made configurable?
• Otherwise: could the canEditShare() condition be removed from the token visibility check, keeping only the permission comparison?

Nextcloud Server version

35

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.5

Web server

Apache (supported)

Database engine version

None

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

Updated from a MINOR version (ex. 32.0.1 to 32.0.2)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

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

No errors have been found

Nextcloud Logs

Additional info

No response