<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Good Morning,</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
This seems to relate to the default squash id of 99. When I changed it to a much higher id the system began functioning as expected (I can mount without explicitly applying the selinux context, I can view files, I can run the df command as root on the area
without first needing to do so as a user).</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
W/r,</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Kurt</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Andreas Dilger <adilger@thelustrecollective.com><br>
<b>Sent:</b> Wednesday, February 25, 2026 11:42 PM<br>
<b>To:</b> Kurt Strosahl <strosahl@jlab.org><br>
<b>Cc:</b> lustre-discuss@lists.lustre.org <lustre-discuss@lists.lustre.org><br>
<b>Subject:</b> Re: [lustre-discuss] [EXTERNAL] lustre-discuss Digest, Vol 239, Issue 19</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Feb 25, 2026, at 10:03, Kurt Strosahl <strosahl@jlab.org> wrote:<br>
> <br>
> 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.<br>
> <br>
> mount -t lustre -o context="system_u:object_r:nfs_t:s0"<br>
<br>
Hmm, should this be added automatically by the "mount" command or "mount.lustre"?<br>
I don't recall anyone else having a similar issue...<br>
<br>
> 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.<br>
<br>
This is because the root user is unable to do the lookup themselves, but<br>
once a non-root user does the lookup it is in the cache and the local<br>
client allows it without checking the MDS. This might relate to<br>
root squash or maybe the identity upcall not being configured correctly?<br>
<br>
Cheers, Andreas<br>
<br>
> <br>
>> From: Kurt Strosahl <strosahl@jlab.org><br>
>> Sent: Monday, February 23, 2026 12:51 PM<br>
>> To: lustre-discuss@lists.lustre.org <lustre-discuss@lists.lustre.org><br>
>> Subject: Re: [EXTERNAL] lustre-discuss Digest, Vol 239, Issue 19<br>
>> I've done some more testing, and when I disable SELinux on the client lustre now mounts, however I've noticed some other oddities...<br>
>> <br>
>> While lustre mounts if I then try to do a df or an lfs df on that area it says<br>
>> [root@qcd24s100 ~]# df /qcd/lustre25
<br>
>> df: /qcd/lustre25: Permission denied <br>
>> [root@qcd24s100 ~]# lfs df /qcd/lustre25
<br>
>> df:/qcd/lustre25 Not a Lustre filesystem<br>
>> <br>
>> 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.<br>
>> <br>
>> <br>
>>> From: Kurt Strosahl <strosahl@jlab.org><br>
>>> Sent: Friday, February 13, 2026 5:03 PM<br>
>>> To: lustre-discuss@lists.lustre.org <lustre-discuss@lists.lustre.org><br>
>>> Subject: Re: [EXTERNAL] lustre-discuss Digest, Vol 239, Issue 19<br>
>>> Yes the default squash is to 99.<br>
>>> <br>
>>> 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 .<br>
>>> <br>
>>> 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.<br>
>>> <br>
>>> 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).<br>
>>> <br>
>>> [root@scmds2501 ~]# lctl get_param -R nodemap.default.*<br>
>>> nodemap.default.admin_nodemap=0<br>
>>> nodemap.default.audit_mode=1<br>
>>> nodemap.default.deny_unknown=0<br>
>>> nodemap.default.exports=<br>
>>> [<br>
>>> { nid: 172.17.1.127@o2ib, uuid: 5dd1bac6-cb91-1169-183d-f084efaba32d }, { nid: 172.17.1.221@o2ib, uuid: bd67c3f7-8a44-4fac-8685-2e234742a2c2 },<br>
>>> ]<br>
>>> nodemap.default.fileset=<br>
>>> nodemap.default.forbid_encryption=0<br>
>>> nodemap.default.id=0<br>
>>> nodemap.default.map_mode=all<br>
>>> nodemap.default.squash_gid=99<br>
>>> nodemap.default.squash_projid=99<br>
>>> nodemap.default.squash_uid=99<br>
>>> nodemap.default.trusted_nodemap=1<br>
>>> <br>
>>> ----------------------------------------------------------------------<br>
>>> <br>
>>> Message: 1<br>
>>> Date: Fri, 13 Feb 2026 14:29:54 +0100<br>
>>> From: Hans Henrik Happe <happe@nbi.dk><br>
>>> To: lustre-discuss@lists.lustre.org<br>
>>> Subject: Re: [lustre-discuss] getting "permission dendied" on mount<br>
>>> when trying to use nodemaps for root squashing<br>
>>> Message-ID: <3b4ae3f4-3b32-43cc-bec5-52b417ab98d5@nbi.dk><br>
>>> Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
>>> <br>
>>> Hi,<br>
>>> <br>
>>> Have you looked at the squash id's. I think they defaults to 99, but <br>
>>> RHEL uses another id for the nobody user.<br>
>>> <br>
>>> A full list of parameters would make it easier to give input. If you <br>
>>> could post this:<br>
>>> <br>
>>> lctl get_param nodemap.default.*<br>
>>> <br>
>>> Cheers,<br>
>>> Hans Henrik<br>
>>> <br>
>>> On 09/02/2026 16.05, Kurt Strosahl via lustre-discuss wrote:<br>
>>> > Good Morning,<br>
>>> ><br>
>>> > ? ?I'm trying to set up nodemaps on a new lustre file system. <br>
>>> > Presently when I turn on the nodemaps I get permission denied for <br>
>>> > servers in the default nodemap.<br>
>>> ><br>
>>> > I've defined two custom nodemaps.? An AdminSystems nodemap (for <br>
>>> > servers that will need to perform actions as root, and a LustreServers <br>
>>> > nodemap (for the lustre servers themselves)<br>
>>> ><br>
>>> > Every other client will be in the default map. (whose gid/uid/projid <br>
>>> > mappings we trust)<br>
>>> ><br>
>>> > I set the following:<br>
>>> > [root@scmds2501 ~]# lctl get_param nodemap.*.admin_nodemap<br>
>>> > nodemap.AdminSystems.admin_nodemap=1<br>
>>> > nodemap.LustreServers.admin_nodemap=1<br>
>>> > Nodemap.default.admin_nodemap=0<br>
>>> ><br>
>>> > [root@scmds2501 ~]# lctl get_param nodemap.*.trusted_nodemap<br>
>>> > nodemap.AdminSystems.trusted_nodemap=1<br>
>>> > nodemap.LustreServers.trusted_nodemap=1<br>
>>> > Nodemap.default.trusted_nodemap=1<br>
>>> ><br>
>>> > When I turn on the nodemap feature I get a permission denied when <br>
>>> > mounting on a client node that isn't in the Admin nodemap.<br>
>>> ><br>
>>> > Interestingly, on a test client that was mounted before I turned on <br>
>>> > the nodemap I can write files as myself (into a directory that I <br>
>>> > established beforehand owned by me).<br>
>>> ><br>
>>> > Our desired end state is an Admin nodemap we can add and remove <br>
>>> > systems to as needed that can take action as root, and all other <br>
>>> > lustre clients being able to access the file system, but having no <br>
>>> > root access.? The LustreServers nodemap is there to keep the lustre <br>
>>> > file servers themselves safe from any unexpected changes.<br>
>>> ><br>
>>> > w/r,<br>
>>> ><br>
>>> > Kurt J. Strosahl (he/him)<br>
>>> > System Administrator: Lustre, HPC<br>
>>> > Scientific Computing Group, Thomas Jefferson National Accelerator Facility<br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > lustre-discuss mailing list<br>
>>> > lustre-discuss@lists.lustre.org<br>
>>> > <a href="https://urldefense.proofpoint.com/v2/url?u=http-">https://urldefense.proofpoint.com/v2/url?u=http-</a><br>
> <br>
> <br>
</div>
</span></font></div>
</body>
</html>