[Bug]: Federation: "Allow download and sync" cannot be checked, breaking local reshares

[gdnmhr]

Bug description

When creating a federated share, the "Allow download and sync" option is ignored and cannot be checked afterwards. When resharing the folder, "Allow download and sync" can be checked in the sharing menu but is not stored (i.e. resets after reloading the page).

If the recipient of the reshare now wants to open a file a message that download is prevented appears ("To view a shared PDF file, the download needs to be allowed for this file share", "This file cannot be displayed as download is disabled by the share" etc.) and the download option is not present. Interestingly this does not affect opening files in Collabora, this still works fine.

This might be related to this issue #48954.

Steps to reproduce

On the server initiating the federated share:

1. Establish a mutual federation between two servers
2. Share a folder with someone on the other server, ensure "Allow download and sync" is checked, give all permissions (i.e. read, edit, create, delete, share)
3. Observe that "Allow download and sync" is unchecked afterwards
4. Try to check "Allow download and sync" later, the UI won't allow to check it

On the server receiving the federated share:
5. Accept the incoming share
6. Try opening & downloading some files
7. Reshare the folder to someone else on this server and grant all permissions
8. Observe that the "Allow download and sync" is checked until you reload the page
9. Try re-checking the "Allow download and sync" option, it seems to work until you reload the page

On the account of the reshare recipient:
10. Browse the files of the share, that works fine
11. Try opening a README, a PDF or some other file that can be previewed and be greeted with one of the above messages
12. Try opening a Textdocument in Collabora and observe that you can edit it as expected.

Expected behavior

Checking "Allow download and sync" should allow the user on the other server to preview and download these files.

Nextcloud Server version

30.0.6 on both Servers
1.20, Federation on both Servers

Additional info

I inspected the database on the receiving server and noticed that in oc_share the attributes of the reshare is [["permissions","download",false]].

Executing UPDATE oc_share SET attributes='[["permissions","download",true]]' where id=xxx; solves the issue and also in the UI the "Allow download and sync" is checked. However, as soon as you click the update button in the share menu, the attribute goes back to false.

[gdnmhr]

I investigated the issue a bit more and found out that it mainly affects resharing the federated share locally. I updated the initial bug report with my new findings.

[patrick-vdw]

Same here!

Nextcloud Hub 9 (30.0.6) on both servers, Federation App 1.20 on both.

When sharing a folder from server A to server B, the administrative user on Server B is actually able to download the shared files. But when this user creates a share for a usergroup on server B, this group cannot download anything.

So none of our "normal" users on the server that recieved the federated share can download any shared files.

[Tegenwind]

Just wanted to chime in to report we've also started encountering this issue recently. It seems to happen mostly for new users added to existing or new shares by group membership, the folders which are shared to adminuser@server.com and then reshared to groups on that server, same as what @patrick-vdw is describing. For existing folders shared with existing users everything seems to work normally still. 🤞🏻

Our current workaround is to re-share the folder to groupname@server.com, but this requires extra interaction from end users to accept the share. If sharing to groupname@server.com is the preferred way going forward it might be nice to have an option to auto-accept shares from trusted federated servers instead, so that this transition could be more seamless.

[gdnmhr]

The combination of #5120, #52180, #52543 has fixed this issue for me after updating to the v31.0.6 release.