You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: new setting show_federated_shares_to_trusted_servers_as_internal returns options for federated shares in the internal section when searching for an email #54511
instances trust each other, and exchange their address book
As shown below, with the parameter show_federated_shares_to_trusted_servers_as_internal set to true, federated cloudId is possible in the External Share search input.
However, when I type an email in the Internal share section input to find the user with that email, I am returned with:
one option for a federeted user,
one for a federated group,
one for the user matching the email
The options for federated user and federated group are unexpected.
Steps to reproduce
Have two nextcloud instances that trust each other and share their address book. Alice is on instance A, Bob on instance B.
Run php occ config:app:set files_sharing show_federated_shares_to_trusted_servers_as_internal --value true --type boolean
With Alice on instance A, input Bob's email address in the Internal Share field input.
Expected behavior
Only Bob's account from the synced address books should show up.
Nextcloud Server version
29
Operating system
None
PHP engine version
None
Web server
None
Database engine version
None
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
But this is exactly what this option does no? show_federated_shares_to_trusted_servers_as_internal should show federated shares to trusted servers as internal.
Thus if trusted servers are now listed in the internal section compared to untrusted which should end up in external shares.
Well what it does is basically only one thing: It makes federated shares behave like internal shares.
So you do not need to create them below in external and then they suddenly move to the upper section - this would be unexpected to have them moved after creation.
Setting show_federated_shares_to_trusted_servers_as_internal is similar (with some restrictions) to just use global scale where federated shares are presented just like internal shares and the user should not see a difference.
additional comment from my side:
with the trusted server thing [1], it is possible to request that servers exchange their account address book. From there, it is possible to search for an account on an other instance directly by typing an email address or a username. No need of a federated cloud ID.
This is why in our case it is useless and confusing for end-users to have matches for potential cloudIDs.
it adds matches for federated cloud IDs in the search results - that is unexpected
No afaik, it adds matches for trusted federated cloud Ids, not just any cloud id. From the screenshot all the servers shown are different domains. So I am not sure why it is unexpected.
show_federated_shares_to_trusted_servers_as_internal does what it is supposed to do, but I think the definition is being streched to treat_federated_shares_to_trusted_servers_as_internal. It is not exactly the same.
Federated shares are still federated shares and we don't know if implementing small things like this that gradually turns one flag to mean another thing is generally going to be accepted behavior for most users or if its the direction we are intentionally trying to take.
@nfebe no it is a bug @maximelehericy showed me the problem on a test instance where only show_federated_shares_to_trusted_servers_as_internal was set.
In this case only trusted federated servers should show up in:
The share list with internal
In search results with internal
But when show_federated_shares_to_trusted_servers_as_internal is set (NOT show_federated_shares_as_internal), then if you search for an email address in the internal share search box, then it also shows (non existing) possible federated cloud ids as suggestions in the internal section.
So the problem:
If show_federated_shares_to_trusted_servers_as_internal is set
but not show_federated_shares_as_internal
AND you configured federation with a TRUSTED server (to share the account list)
Then you try to search for a FEDERATED user using its EMAIL address in the INTERNAL share section.
Expected:
Only see the federated user with that cloud id
Current behavior:
you get the federated user with the correct email address ✅
you also get a suggestion for a non existing, non trusted possible federated user with this email address as cloud id ❌
Meaning you type name@mail.example.com you expect only a federated user with that mail address, but you also get a suggestion for user name on instance mail.example.com which is not a trusted server and not existing (e.g. the user would be name on cloud.example.com but with that email address).
Activity
susnux commentedon Aug 19, 2025
But this is exactly what this option does no?
show_federated_shares_to_trusted_servers_as_internalshould show federated shares to trusted servers as internal.Thus if trusted servers are now listed in the internal section compared to untrusted which should end up in external shares.
maximelehericy commentedon Aug 20, 2025
@susnux I am referring to what the search returns rather than where the share ends up once it is created.
The parameter
show_federated_shares_to_trusted_servers_as_internaldoes two things where I expect it to do only one:susnux commentedon Aug 20, 2025
Well what it does is basically only one thing: It makes federated shares behave like internal shares.
So you do not need to create them below in external and then they suddenly move to the upper section - this would be unexpected to have them moved after creation.
Setting
show_federated_shares_to_trusted_servers_as_internalis similar (with some restrictions) to just use global scale where federated shares are presented just like internal shares and the user should not see a difference.maximelehericy commentedon Aug 21, 2025
additional comment from my side:
with the trusted server thing [1], it is possible to request that servers exchange their account address book. From there, it is possible to search for an account on an other instance directly by typing an email address or a username. No need of a federated cloud ID.
This is why in our case it is useless and confusing for end-users to have matches for potential cloudIDs.
[1] https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/federated_cloud_sharing_configuration.html#configuring-trusted-nextcloud-servers
nfebe commentedon Sep 9, 2025
No afaik, it adds matches for trusted federated cloud Ids, not just any cloud id. From the screenshot all the servers shown are different domains. So I am not sure why it is unexpected.
show_federated_shares_to_trusted_servers_as_internaldoes what it is supposed to do, but I think the definition is being streched totreat_federated_shares_to_trusted_servers_as_internal. It is not exactly the same.Federated shares are still federated shares and we don't know if implementing small things like this that gradually turns one flag to mean another thing is generally going to be accepted behavior for most users or if its the direction we are intentionally trying to take.
This is feature request-ish.
cc: @marcoambrosini @jancborchardt any product or design opinions on this?
susnux commentedon Sep 9, 2025
@nfebe no it is a bug @maximelehericy showed me the problem on a test instance where only
show_federated_shares_to_trusted_servers_as_internalwas set.In this case only trusted federated servers should show up in:
But when
show_federated_shares_to_trusted_servers_as_internalis set (NOTshow_federated_shares_as_internal), then if you search for an email address in the internal share search box, then it also shows (non existing) possible federated cloud ids as suggestions in the internal section.So the problem:
show_federated_shares_to_trusted_servers_as_internalis setshow_federated_shares_as_internalThen you try to search for a FEDERATED user using its EMAIL address in the INTERNAL share section.
Expected:
Current behavior:
Meaning you type
name@mail.example.comyou expect only a federated user with that mail address, but you also get a suggestion for usernameon instancemail.example.comwhich is not a trusted server and not existing (e.g. the user would benameoncloud.example.combut with that email address).12 remaining items
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs
fix(sharing): Adapt share suggestions to match trusted servers configs