From ab6443f6400ac311d4d977456214d0546049876a Mon Sep 17 00:00:00 2001 From: whoalin1 Date: Wed, 7 Oct 2026 02:35:42 +0300 Subject: [PATCH 1/2] docs(admin): warn that LDAP gidNumber keeps group membership Assisted-by: Cursor:grok-4.7 Signed-off-by: whoalin1 --- .../configuration_user/user_auth_ldap.rst | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/admin_manual/configuration_user/user_auth_ldap.rst b/admin_manual/configuration_user/user_auth_ldap.rst index 057b39f2aa6..6cc6307d533 100644 --- a/admin_manual/configuration_user/user_auth_ldap.rst +++ b/admin_manual/configuration_user/user_auth_ldap.rst @@ -392,6 +392,26 @@ Group Member association: * Example: *uniquemember* +.. warning:: + Matching a user's ``gidNumber`` to a group's ``gidNumber`` also makes + Nextcloud treat that user as a member of the group. This is the POSIX + primary-group mechanism. It applies **in addition to** (and independently + of) whatever you configure here — for example ``member``, ``memberUid``, + or ``uniqueMember``. + + So after you remove a user from an LDAP group via the usual membership + attribute, they may still appear as a member in the web UI and in + ``occ`` output while their ``gidNumber`` still matches the group's. The + same idea applies to Active Directory ``primaryGroupID``. The attribute + name used for the user-side value is configurable as ``ldapGidNumber`` + (default ``gidNumber``) via the LDAP configuration API / ``occ``, but it + is not exposed in the admin UI. + + Prefer distinct ``gidNumber`` namespaces for users versus groups, or + change the user's ``gidNumber`` / ``primaryGroupID`` when membership + should end. ``ldap:show-remnants`` only lists deleted users and does not + clear this secondary relation. + Nested groups: Enable group member retrieval from sub groups. From c17a053cf4fd8170bdac88725f2034ecf9853748 Mon Sep 17 00:00:00 2001 From: whoalin1 Date: Fri, 23 Oct 2026 19:41:57 +0300 Subject: [PATCH 2/2] docs(admin): drop unclear show-remnants paragraph from LDAP gidNumber note Assisted-by: Cursor:grok-4.7 Signed-off-by: whoalin1 --- admin_manual/configuration_user/user_auth_ldap.rst | 5 ----- 1 file changed, 5 deletions(-) diff --git a/admin_manual/configuration_user/user_auth_ldap.rst b/admin_manual/configuration_user/user_auth_ldap.rst index 6cc6307d533..d6515e0ea2f 100644 --- a/admin_manual/configuration_user/user_auth_ldap.rst +++ b/admin_manual/configuration_user/user_auth_ldap.rst @@ -407,11 +407,6 @@ Group Member association: (default ``gidNumber``) via the LDAP configuration API / ``occ``, but it is not exposed in the admin UI. - Prefer distinct ``gidNumber`` namespaces for users versus groups, or - change the user's ``gidNumber`` / ``primaryGroupID`` when membership - should end. ``ldap:show-remnants`` only lists deleted users and does not - clear this secondary relation. - Nested groups: Enable group member retrieval from sub groups.