镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

[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

Closed

Description

@maximelehericy

⚠️ This issue respects the following points: ⚠️

Bug description

Context:

  • federated setup (at least two instances)
  • 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.
Image

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
Image

The options for federated user and federated group are unexpected.

Steps to reproduce

  1. Have two nextcloud instances that trust each other and share their address book. Alice is on instance A, Bob on instance B.
  2. Run php occ config:app:set files_sharing show_federated_shares_to_trusted_servers_as_internal --value true --type boolean
  3. 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.

Image

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?

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

Related PR: #53661

Activity

  1. susnux commented on Aug 19, 2025

    @susnux
    Contributor

    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.

  2. maximelehericy commented on Aug 20, 2025

    @maximelehericy
    Author

    @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_internal does two things where I expect it to do only one:

    1. it puts a share to an account from a trusted server in the Internal share section, once the share is created. - that is expected
    2. it adds matches for federated cloud IDs in the search results - that is unexpected
  3. susnux commented on Aug 20, 2025

    @susnux
    Contributor

    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.

  4. maximelehericy commented on Aug 21, 2025

    @maximelehericy
    Author

    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

  5. self-assigned this
    on Sep 9, 2025
  6. nfebe commented on Sep 9, 2025

    @nfebe
    Contributor

    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.

    This is feature request-ish.

    cc: @marcoambrosini @jancborchardt any product or design opinions on this?

  7. susnux commented on Sep 9, 2025

    @susnux
    Contributor

    @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:

    1. The share list with internal
    2. 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).

  8. 12 remaining items

  9. added 8 commits that reference this issue on Oct 1, 2025
    b9640f0
    4e68573
    8579562
    6b812fe
    c236f5f
    177d73c
    355d91a
    c1d9e22
  10. added 2 commits that reference this issue on Oct 9, 2025
    7e2f87c
    516289c
  11. added 2 commits that reference this issue on Nov 11, 2025
    cc07f74
    75179f9
  12. added a commit that references this issue on Dec 15, 2025
    f94d30c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions