[lustre-discuss] [EXTERNAL] lustre-discuss Digest, Vol 239, Issue 19
Andreas Dilger
adilger at thelustrecollective.com
Wed Feb 25 20:42:39 PST 2026
On Feb 25, 2026, at 10:03, Kurt Strosahl <strosahl at jlab.org> wrote:
>
> After further work... I was able to get a client in the default nodemap to mount with SELinux enabled. This was done by passing the selinux context explicitly in the mount command.
>
> mount -t lustre -o context="system_u:object_r:nfs_t:s0"
Hmm, should this be added automatically by the "mount" command or "mount.lustre"?
I don't recall anyone else having a similar issue...
> note though that I'm still not able to df or lfs the lustre mountpoint directly UNTIL a non-root users runs such a command.
This is because the root user is unable to do the lookup themselves, but
once a non-root user does the lookup it is in the cache and the local
client allows it without checking the MDS. This might relate to
root squash or maybe the identity upcall not being configured correctly?
Cheers, Andreas
>
>> From: Kurt Strosahl <strosahl at jlab.org>
>> Sent: Monday, February 23, 2026 12:51 PM
>> To: lustre-discuss at lists.lustre.org <lustre-discuss at lists.lustre.org>
>> Subject: Re: [EXTERNAL] lustre-discuss Digest, Vol 239, Issue 19
>> I've done some more testing, and when I disable SELinux on the client lustre now mounts, however I've noticed some other oddities...
>>
>> While lustre mounts if I then try to do a df or an lfs df on that area it says
>> [root at qcd24s100 ~]# df /qcd/lustre25
>> df: /qcd/lustre25: Permission denied
>> [root at qcd24s100 ~]# lfs df /qcd/lustre25
>> df:/qcd/lustre25 Not a Lustre filesystem
>>
>> However if I just do a df without specifying the directory it shows up. Further if I run a lfs df as myself I can see it... and then root can also see it.
>>
>>
>>> From: Kurt Strosahl <strosahl at jlab.org>
>>> Sent: Friday, February 13, 2026 5:03 PM
>>> To: lustre-discuss at lists.lustre.org <lustre-discuss at lists.lustre.org>
>>> Subject: Re: [EXTERNAL] lustre-discuss Digest, Vol 239, Issue 19
>>> Yes the default squash is to 99.
>>>
>>> I did test setting the squash_g/uid to 0, and the behaviour did change. But that just seems to let root take actions on files/dirs owned by root .
>>>
>>> Is that how the nodemaps are supposed to work? It seems odd to me that setting admin to off and trusted to on doesn't allow clients to mount unless I also go in and set root to 0:0.
>>>
>>> Under the old way you just set the squash u/gid and then set your norootsquash list (a method I've been using for years).
>>>
>>> [root at scmds2501 ~]# lctl get_param -R nodemap.default.*
>>> nodemap.default.admin_nodemap=0
>>> nodemap.default.audit_mode=1
>>> nodemap.default.deny_unknown=0
>>> nodemap.default.exports=
>>> [
>>> { nid: 172.17.1.127 at o2ib, uuid: 5dd1bac6-cb91-1169-183d-f084efaba32d }, { nid: 172.17.1.221 at o2ib, uuid: bd67c3f7-8a44-4fac-8685-2e234742a2c2 },
>>> ]
>>> nodemap.default.fileset=
>>> nodemap.default.forbid_encryption=0
>>> nodemap.default.id=0
>>> nodemap.default.map_mode=all
>>> nodemap.default.squash_gid=99
>>> nodemap.default.squash_projid=99
>>> nodemap.default.squash_uid=99
>>> nodemap.default.trusted_nodemap=1
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Fri, 13 Feb 2026 14:29:54 +0100
>>> From: Hans Henrik Happe <happe at nbi.dk>
>>> To: lustre-discuss at lists.lustre.org
>>> Subject: Re: [lustre-discuss] getting "permission dendied" on mount
>>> when trying to use nodemaps for root squashing
>>> Message-ID: <3b4ae3f4-3b32-43cc-bec5-52b417ab98d5 at nbi.dk>
>>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>
>>> Hi,
>>>
>>> Have you looked at the squash id's. I think they defaults to 99, but
>>> RHEL uses another id for the nobody user.
>>>
>>> A full list of parameters would make it easier to give input. If you
>>> could post this:
>>>
>>> lctl get_param nodemap.default.*
>>>
>>> Cheers,
>>> Hans Henrik
>>>
>>> On 09/02/2026 16.05, Kurt Strosahl via lustre-discuss wrote:
>>> > Good Morning,
>>> >
>>> > ? ?I'm trying to set up nodemaps on a new lustre file system.
>>> > Presently when I turn on the nodemaps I get permission denied for
>>> > servers in the default nodemap.
>>> >
>>> > I've defined two custom nodemaps.? An AdminSystems nodemap (for
>>> > servers that will need to perform actions as root, and a LustreServers
>>> > nodemap (for the lustre servers themselves)
>>> >
>>> > Every other client will be in the default map. (whose gid/uid/projid
>>> > mappings we trust)
>>> >
>>> > I set the following:
>>> > [root at scmds2501 ~]# lctl get_param nodemap.*.admin_nodemap
>>> > nodemap.AdminSystems.admin_nodemap=1
>>> > nodemap.LustreServers.admin_nodemap=1
>>> > Nodemap.default.admin_nodemap=0
>>> >
>>> > [root at scmds2501 ~]# lctl get_param nodemap.*.trusted_nodemap
>>> > nodemap.AdminSystems.trusted_nodemap=1
>>> > nodemap.LustreServers.trusted_nodemap=1
>>> > Nodemap.default.trusted_nodemap=1
>>> >
>>> > When I turn on the nodemap feature I get a permission denied when
>>> > mounting on a client node that isn't in the Admin nodemap.
>>> >
>>> > Interestingly, on a test client that was mounted before I turned on
>>> > the nodemap I can write files as myself (into a directory that I
>>> > established beforehand owned by me).
>>> >
>>> > Our desired end state is an Admin nodemap we can add and remove
>>> > systems to as needed that can take action as root, and all other
>>> > lustre clients being able to access the file system, but having no
>>> > root access.? The LustreServers nodemap is there to keep the lustre
>>> > file servers themselves safe from any unexpected changes.
>>> >
>>> > w/r,
>>> >
>>> > Kurt J. Strosahl (he/him)
>>> > System Administrator: Lustre, HPC
>>> > Scientific Computing Group, Thomas Jefferson National Accelerator Facility
>>> >
>>> >
>>> > _______________________________________________
>>> > lustre-discuss mailing list
>>> > lustre-discuss at lists.lustre.org
>>> > https://urldefense.proofpoint.com/v2/url?u=http-
>
>
More information about the lustre-discuss
mailing list