[lustre-discuss] how to unsquash users

[Sebastien Buisson]

That is correct, in your case you should set admin and trusted to 1 on your default nodemap. But that is not really the recommended way to work with nodemaps. The default nodemap should be restrictive so that unknown clients ending up in this group are not granted any privileges. And then you create specific nodemaps for your different uses cases.

Also, as explained in the Lustre Operations Manual in section 28.2.2:
https://doc.lustre.org/lustre_manual.xhtml#idm139897458337088
The administrative site for the Lustre file system needs at least one group with both admin and trusted properties in order to perform maintenance or to perform administrative tasks. And, more importantly, Lustre server nodes *must* be in a policy group with both these properties set to 1.

HTH,
Sebastien.

> Le 20 mai 2022 à 18:28, Julien Rey <julienrey76 at gmail.com> a écrit :
> 
> Hello Sebastien,
> 
> Thanks for your clear explanation.
> 
> I managed to "unsquash" my directory's ownership with a simple chown and without having to re-mount the lustre filesystem.
> 
> I understand that I should activate the "admin" and "trusted" properties on the default nodemap to turn it off completely for the rest of the clients. Am I correct ?
> 
> J.
> 
> Le 20/05/2022 à 17:10, Sebastien Buisson a écrit :
>> Hi,
>> 
>> It looks like you did not set properties on the default nodemap, which gets involved for your machine not in the 10.0.1.[35-38] range.
>> When in use, the nodemap feature does not change anything about UID/GID of files as stored on servers, it just changes (maps) the way clients see them. Once deactivated, you should unmount then remount Lustre on your client (I understand that you have your home directories on Lustre?).
>> 
>> Also, if you set the trusted property on the ’seamless’ nodemap, no id or gid mapping will be actually carried out, because by definition it means you trust the file system's canonical identifiers.
>> 
>> HTH,
>> Sebastien.
>> 
>>> Le 20 mai 2022 à 16:57, Julien Rey via lustre-discuss <lustre-discuss at lists.lustre.org> a écrit :
>>> 
>>> Hello everyone,
>>> 
>>> We are running lustre 2.12.7 and today I tried to set up a few nodemaps so as to restrict access to an unique user (seamless user with uid/gid 3669) to a subdirectory (/webservices/seamless) from a range of machines (10.0.1.[35-38]).
>>> 
>>> Here's what I did so far :
>>> 
>>> lctl nodemap_add seamless
>>> 
>>> lctl nodemap_add_range --name seamless --range 10.0.1.[35-38]@tcp
>>> 
>>> lctl nodemap_modify --name seamless --property trusted --value 1
>>> 
>>> lctl nodemap_add_idmap --name seamless --idtype uid --idmap 3669:3669
>>> 
>>> lctl nodemap_add_idmap --name seamless --idtype gid --idmap 3669:3669
>>> 
>>> lctl nodemap_set_fileset --name seamless --fileset '/webservices/seamless'
>>> 
>>> lctl nodemap_activate 1
>>> 
>>> 
>>> However, when I tried to log on one of the machine NOT in the 10.0.1.[35-38] range with my user account (uid 2154), my home directory ownership got immediately squashed to:
>>> 
>>> drwx------ 12 nobody nobody 4096 Apr 5 17:11 rey
>>> 
>>> So I immediatly deactivated the nodemaps using :
>>> 
>>> lctl nodemap_activate 0
>>> 
>>> However, the directory ownership remains nobody/nobody and I can no longer log in.
>>> 
>>> 
>>> Does anyone know how to revert this ? And what was wrong with my nodemaps configuration ?
>>> 
>>> Thanks.
>>> 
>>> -- 
>>> Julien REY
>>> 
>>> Plate-forme RPBS
>>> Modélisation Computationnelle des Interactions Protéines-Ligand (CMPLI)
>>> Université de Paris
>>> tel : 01 57 27 83 95
>>> 
>>> _______________________________________________
>>> lustre-discuss mailing list
>>> lustre-discuss at lists.lustre.org
>>> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
> 
> -- 
> Julien REY
> 
> Plate-forme RPBS
> Modélisation Computationnelle des Interactions Protéines-Ligand (CMPLI)
> Université de Paris
> tel : 01 57 27 83 95