Missing oc_share entries for SAML-provisioned users in existing groups after SAML-provisioning

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Steps to reproduce

1. Provision a new user via SAML and ensure they are automatically assigned to an existing group (e.g., Group A) that has shared folders (e.g., Folder A).
2. Log in as the newly provisioned user.
3. Verify whether the group-shared folder (e.g., Folder A) is visible and accessible to the user.

Alternative scenario:

1. Log in as an existing user.
2. Assign the user to a new SAML-provisioned group (e.g., Group B) that has shared folders (e.g., Folder B).
3. Verify whether the newly assigned group-shared folder (e.g., Folder B) is visible and accessible to the user.

Expected behaviour

When a user is added to a SAML-provisioned group, shared folders and files that were previously assigned to the group should be automatically available to the new user. Entries in the oc_share table should be generated accordingly, ensuring access to group-shared resources.

For example:

• Folder A is shared with Group A.
• User X is added to the system and automatically assigned to SAML Group A.
• User X should immediately see Folder A and have access to the shared content, with corresponding entries in the oc_share table.

Actual behaviour

Currently, when a new user is provisioned via SAML and added to an existing group (e.g., Group A), the group-shared files and folders (e.g., Folder A) do not appear for the user. Although the share exists, no entries are created in the oc_share table to provide access.

If you manually add the user to the group through the Nextcloud backend or reassign the permissions on the folders, the oc_share entries are correctly created, and the user gains access to the shared resources.

This issue did not exist in version 5.27 but appears to be a regression in the current version.

Workaround (temporary fix):

In my instance, I’ve created a trigger for the oc_group_user table that temporarily addresses the issue. The trigger ensures that whenever a new gid-uid combination is added, the corresponding entries in the oc_share table are created or deleted accordingly. However, this should not be considered a permanent solution, as it only works as a temporary fix to handle the missing share entries in this specific instance.

Server configuration

Official Nextcloud Docker (nextcloud:30)

Web server: Apache/Nginx
Database: MariaDB
PHP version: 8.2.24
Nextcloud version: 30.0.0

Start by reproducing SAML provisioning into an existing group with a shared folder, then inspect how additions to oc_group_user are handled and whether corresponding oc_share entries are generated. Compare the provisioning path with manually adding a user to a group; the issue is done when newly provisioned or assigned users can access existing group-shared resources without the database trigger workaround.