Ole Holm Nielsen <ole.h.niel...@fysik.dtu.dk> writes: > On 9/21/21 9:11 AM, Amjad Syed wrote: >> We have users who have have defined unix secondary id on our login nodes. >> >> vas20xhu@login01 ~]$ groups >> >> BIO_pg BIO_AFMAKAY_LAB_USERS >> >> But when we run interactive and go to compute node , the user does not have >> secondary group of BIO_AFMAKAY_LAB_USERS >> >> vas20xhu@c0077 ~]$ groups >> >> BIO_pg > > I believe that Slurm creates users in the database using the primary UNIX > group > name. Slurm would not know about any secondary UNIX groups. > > There must be a uniform user and group name space (including UIDs and GIDs) > across the cluster. It is your own responsibility to configure users and > groups > in the passwd and group databases consistently, see > https://slurm.schedmd.com/quickstart_admin.html (search for GIDs). > > FWIW, I have some information about creation of users and groups in this Wiki > page: > https://wiki.fysik.dtu.dk/niflheim/Slurm_accounting#create-accounts-and-users
I would have thought that this maybe does not have anything to do with Slurm. Assuming you are using SSSD, it looks to me more like the settings in sssd.conf on the nodes might be incorrect. In our sssd.conf I found the following note to myself: # LB: rfc2307bis should not be used if memberUid is used for group membership # otherwise secondary groups fail # ldap_schema = rfc2307bis What schema you need depends on how your group information is stored. rfc2307 assumes the groups just have a memberUID, whereas with rfc2307bis the users also have a memberOf attribute. I don't understand LDAP well enough to understand why rfc2307bis causes the secondary group resolution to fail, even though the groups still have the information via memberUID, but my experience was that it does indeed fail. Cheers, Loris -- Dr. Loris Bennett (Hr./Mr.) ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de