On Feb 25, 2026, at 10:03, Kurt Strosahl <[email protected]> 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 <[email protected]> >> Sent: Monday, February 23, 2026 12:51 PM >> To: [email protected] <[email protected]> >> 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@qcd24s100 ~]# df /qcd/lustre25 >> >> >> df: /qcd/lustre25: Permission denied >> [root@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 <[email protected]> >>> Sent: Friday, February 13, 2026 5:03 PM >>> To: [email protected] <[email protected]> >>> 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@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@o2ib, uuid: 5dd1bac6-cb91-1169-183d-f084efaba32d }, { >>> nid: 172.17.1.221@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 <[email protected]> >>> To: [email protected] >>> Subject: Re: [lustre-discuss] getting "permission dendied" on mount >>> when trying to use nodemaps for root squashing >>> Message-ID: <[email protected]> >>> 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@scmds2501 ~]# lctl get_param nodemap.*.admin_nodemap >>> > nodemap.AdminSystems.admin_nodemap=1 >>> > nodemap.LustreServers.admin_nodemap=1 >>> > Nodemap.default.admin_nodemap=0 >>> > >>> > [root@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 >>> > [email protected] >>> > https://urldefense.proofpoint.com/v2/url?u=http- > > _______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
