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

[rthaler]

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

[blizzz]

As of 6.1.0 the SAML backend ships its own group backend. It used to be the case that groups were created in the local database backend, which caused a mess with strange side effects. Now the challenge is to migrate the proper groups back. But if Group A also has members that do not belong to the SAML backend they are not considered belonging to SAML and stay in the local backend, while a new group is created within the SAML backend with the same display name, but prefixed group id. I suppose this is what happened here.

[rthaler]

As of 6.1.0 the SAML backend ships its own group backend. It used to be the case that groups were created in the local database backend, which caused a mess with strange side effects. Now the challenge is to migrate the proper groups back. But if Group A also has members that do not belong to the SAML backend they are not considered belonging to SAML and stay in the local backend, while a new group is created within the SAML backend with the same display name, but prefixed group id. I suppose this is what happened here.

Is it possible to disable the new behavior where share links are only created if there are no local users in the group? In our case, we have a local user, through whom folders are created and permissions are assigned via the API, and this user is also the owner of the folders.

Specifically, we manage folders for approximately ~10k students, who are automatically granted read access to their study-related folders, with access being revoked at the end of each semester. The management tool handles folder creation and permission assignments, and it also creates users in Keycloak and assigns roles/groups there via the API - which creates problems mentioned in ticket 879. Additionally, the management system has a local user who inserts files into the folders.

Based on your explanation, I understand that, starting from version 6.1.0, it is no longer possible to have both local and SAML users in the same group - which breaks our workflow. While debugging the code, it seems that the groups are being created, and $group->addUser($user) is executed as expected, with users being assigned to the groups. As you mentioned, the issue might indeed be related to the presence of local users in the group.

To clarify, am I correct in understanding that if I remove all local users from the groups, the share links should be created properly?

[blizzz]

Is it possible to disable the new behavior where share links are only created if there are no local users in the group? In our case, we have a local user, through whom folders are created and permissions are assigned via the API, and this user is also the owner of the folders.

This not bound to shares, but to group provisioning. If the local user is part of that group, this is why it happens.

Based on your explanation, I understand that, starting from version 6.1.0, it is no longer possible to have both local and SAML users in the same group - which breaks our workflow.

It is possible, but only in a local group, which then is not managed by the SAML backend however.

To clarify, am I correct in understanding that if I remove all local users from the groups, the share links should be created properly?

This is correct, although if this already is on prod and the original group is not in the transition list anymore, then probably some handwork is necessary. The group management is also described at https://portal.nextcloud.com/article/Authentication/Single-Sign-On-(SSO)/SAML-Group-Management, however available to customers, as the SAML backend is not considered a home user functionality.