NFS Name Mapping Windows -> Unix root and no_root_squash

[Hermes]

I read through the manuals but it seems I dont quite understand how to properly set up an NFS Storage with no_root_squash and Name Mapping for my Domain Admins to Root.

Goal:
Have NFS Storage that I can mount on my Linux Box. Linux Box is connected with AD. I want to be able to create Folders/Files as root:root and also with my domain users domuser@domain:domgroup@domain. Preferably with NFS4.0 so I can use ACL and set multiple permission Groups on Folders/Files.

Set Up is now as following
Cluster: 10.0.0.5
Client: 10.0.0.10
SVM: SMB

Volume: nfs_sftp
QTree: qtree_nfs_sftp

vserver export-policy rule show -vserver SMB -policyname exp_NFS_SFTP -ruleindex 1


                                    Vserver: SMB
                                Policy Name: exp_NFS_SFTP
                                 Rule Index: 1
                            Access Protocol: nfs
List of Client Match Hostnames, IP Addresses, Netgroups, or Domains: 10.0.0.10
                             RO Access Rule: any
                             RW Access Rule: any
User ID To Which Anonymous Users Are Mapped: 65534
                   Superuser Security Types: sys
               Honor SetUID Bits in SETATTR: true
                  Allow Creation of Devices: true

volume show -vserver SMB -volume nfs_sftp -fields policy

vserver       volume   policy       
------------- -------- ------------ 
SMB           nfs_sftp exp_NFS_SFTP 

nfs show -vserver SMB -instance


                                        Vserver: SMB
                             General NFS Access: true
                                         NFS v3: enabled
                                       NFS v4.0: enabled
                                   UDP Protocol: enabled
                                   TCP Protocol: enabled
                           Default Windows User: 
                            NFSv4.0 ACL Support: enabled
                NFSv4.0 Read Delegation Support: disabled
               NFSv4.0 Write Delegation Support: disabled
                        NFSv4 ID Mapping Domain: localdomain
            NFSv4 Grace Timeout Value (in secs): 45
Preserves and Modifies NFSv4 ACL (and NTFS File Permissions in Unified Security Style): enabled
                  NFSv4.1 Minor Version Support: disabled
                                  Rquota Enable: disabled
                   NFSv4.1 Parallel NFS Support: enabled
                            NFSv4.1 ACL Support: disabled
                           NFS vStorage Support: disabled
            NFSv4 Support for Numeric Owner IDs: enabled
                          Default Windows Group: -
                NFSv4.1 Read Delegation Support: disabled
               NFSv4.1 Write Delegation Support: disabled
                            NFS Mount Root Only: enabled
                                  NFS Root Only: disabled
            Permitted Kerberos Encryption Types: des, des3, aes-128, aes-256
                              Showmount Enabled: enabled
Set the Protocol Used for Name Services Lookups for Exports: udp
                    NFSv3 MS-DOS Client Support: disabled
     Idle Connection Timeout Value (in seconds): 360
             Are Idle NFS Connections Supported: disabled
Hide Snapshot Directory under NFSv3 Mount Point: disabled
           Provide Root Path as Showmount State: disabled

vserver name-mapping show -vserver SMB 

Vserver:   SMB
Direction: win-unix
Position Hostname         IP Address/Mask
-------- ---------------- ----------------
1       -                 -                   Pattern: Domain\\User1
                                          Replacement: root

My Issue now is:

With NFS4.1 activated and a Standard Domain User set im able to mount and list everything in it but when I create a Folder its owner is shown as root but reroutet to nobody.

root@ubuntu:/# mount -t nfs 10.0.0.5:/nfs_sftp/qtree_nfs_sftp /mnt

root@ubuntu:/mnt# ls -la
total 12
drwxrwxrwx  3 root root 4096 Aug  6 11:30 .
drwxr-xr-x 21 root root 4096 Jul 22 09:18 ..
drwx------  3 root root 4096 Aug  6 11:32 testfolder

root@ubuntu:/mnt# getfacl testfolder/
# file: testfolder/
# owner: root
# group: root
user::rwx
group::---
other::---

root@ubuntu:/mnt# setfacl -m g:domaingrp:rwx testfolder/
setfacl: testfolder/: Operation not supported

With NFS4.0 activated im not able to mount the Share.

root@ubuntu:/# mount -t nfs 10.0.0.5:/nfs_sftp/qtree_nfs_sftp /mnt
mount.nfs: access denied by server while mounting 10.0.0.5:/nfs_sftp/qtree_nfs_sftp

With NFS3 activated I can mount the share but have no permission to list whats in it, I also created the "exp_NFS_SFTP" file to refer to the Export Policy as suggested in the Manual.

I def did not quite understand how to properly configure it so Im full of hope someone can point me in the right directions.

[Hermes]

I know. I studied that part multiple times. tbh its quite poorly described how that feature works. As I understood you create the export policy and link to that export policy by creating a file in the root of the directory with the name the policy has.

vserver export-policy rule show -vserver SMB -policyname exp_NFS_SFTP -ruleindex 1    

                                    Vserver: SMB
                                Policy Name: exp_NFS_SFTP
                                 Rule Index: 1
                            Access Protocol: nfs
List of Client Match Hostnames, IP Addresses, Netgroups, or Domains: 10.0.0.10
                             RO Access Rule: sys
                             RW Access Rule: sys
User ID To Which Anonymous Users Are Mapped: 65534
                   Superuser Security Types: any
               Honor SetUID Bits in SETATTR: true
                  Allow Creation of Devices: true

root@ubuntu:/mnt# ll
total 16
drwxr-xr-x  4 root root 4096 Aug  6 13:53 ./
drwxr-xr-x 21 root root 4096 Jul 22 09:18 ../
drwx------  3 root root 4096 Aug  6 13:04 SFTPdata/
-rwxrwxrwx  1 root root    0 Aug  6 11:37 exp_NFS_SFTP* << The File
drwxr-xr-x  2 root root 4096 Aug  6 13:53 testfolder/

[parisi]

I don't know how you got "create a file in the root of the directory" from that section. The file created is to show which policy was used in which instance. Nowhere did it say you need to create a file with the same name to make it work.

The part you need to pay attention to is:

Squashing Root

The following examples show how to squash root to anon in various configuration scenarios.
Example 1: Root is squashed to the anon user for all clients.
This approach uses superuser for all NFS clients using sec=sys; other sec types are denied access.

cluster::> vserver export-policy rule show –policyname root_squash -instance
(vserver export-policy rule show)
Vserver: vs0
Policy Name: root_squash
Rule Index: 1
Access Protocol: nfs <- only NFS is allowed (NFSv3 and v4)
Client Match Hostname, IP Address, Netgroup, or Domain: 0.0.0.0/0 <- all clients
RO Access Rule: sys <- only AUTH_SYS is allowed
RW Access Rule: sys <- only AUTH_SYS is allowed
User ID To Which Anonymous Users Are Mapped: 65534 <- mapped to 65534
Superuser Security Types: none <- superuser (root) squashed to anon user
Honor SetUID Bits in SETATTR: true
Allow Creation of Devices: true

And:

Example 2: Root is squashed to the anon user using superuser for a specific client.
In this example, sec=sys and sec=none are allowed.
cluster::> vserver export-policy rule show –policyname root_squash_client -instance
(vserver export-policy rule show)
Vserver: vs0
Policy Name: root_squash_client
118 NFS in NetApp ONTAP: Best Practices and Implementation Guide © 2020 NetApp, Inc. All Rights Reserved.
Rule Index: 1
Access Protocol: nfs <- only NFS is allowed (NFSv3 and v4)
Client Match Hostname, IP Address, Netgroup, or Domain: x.x.x.x <- just this client
RO Access Rule: sys,none <- AUTH_SYS and AUTH_NONE are allowed
RW Access Rule: sys,none <- AUTH_SYS and AUTH_NONE are allowed
User ID To Which Anonymous Users Are Mapped: 65534 <- mapped to 65534
Superuser Security Types: none <- superuser (root) squashed to anon user
Honor SetUID Bits in SETATTR: true
Allow Creation of Devices: true

[Hermes]

ookay. So set "Allow Superuser Access" IS no_root_squash.

the part with "[root@nfsclient mnt]# touch root_allow_krb5_only" was misleading for me.

Then it seems with actually having set the propper name mapping all is done.

So far, with all those settings it works for me. I can mount and I can create files and so on.

There is only one thing left I dont understand.

Having UNIX set, mapped root to a domain user so if he needs windows authentication (for example to be able to mount the drive), folders created as root:root and so on .. how can I now set an acl on that folder.

vserver nfs show -vserver SMB -fields v4.0-acl 
vserver       v4.0-acl 
------------- -------- 
SMB           enabled 

root@ubuntu:/mnt# getfacl SFTPdata/
# file: SFTPdata/
# owner: root
# group: root
user::rwx
group::---
other::---

root@ubuntu:/mnt# setfacl -m g:Domänen-Admins@domain:rwx SFTPdata/
setfacl: SFTPdata/: Operation not supported

[parisi]

You can't set NFSv4.x ACLs on NTFS security styles. And you can't set NTFS ACLs on UNIX security styles.

Mixed allows you to set ACLs from either protocol, but it will toggle the effective security style each time, which changes how name mappings work.

So I'd recommend picking the way you want to set ACLs (either NFSv4 or NTFS) and set the security style to that.

[Hermes]

The Issue is: Now when I set root:root with 700 only root has access to that folder and sub folder. And I need a workaround for this for my Domain Admins. My thought was to add ACL's to not only have root:root but also x:domainadmin@domain but maybe I missunderstood how ACL works.

Can I workaround this with name mapping?

vserver name-mapping show -vserver SMB -direction win-unix 

Vserver:   SMB
Direction: win-unix
Position Hostname         IP Address/Mask
-------- ---------------- ----------------
1       -                 -                   Pattern: Domain\\DomAdmin1
                                          Replacement: root
2       -                 -                   Pattern: Domain\\DomAdmin2
                                          Replacement: root
2 entries were displayed.

[parisi]

Your options are:

1) Keep NTFS security style and set ACLs for the user that root maps to, as well as the group you want.

2) Keep UNIX security style and set NFSv4 ACLs for root and the group.

If name mappings are working properly, then users will map across protocols and get the proper ACLs.

[Hermes]

After thinking about it I stay with UNIX mode.

I set the name mapping properly and I think I found kind of the issue why I still cant access the folder I set to root:root

vserver services access-check authentication show-creds -vserver SMB -win-name DomAdmin1

UNIX UID: root <> Windows User: Domain\DomAdmin1 (Windows Domain User)

 GID: daemon <<< I think the assigned group is the issue
 Supplementary GIDs: 
  daemon

I think it might be the issue that the GID is set to daemon? Am I in the right direction here?

It does map my user to root, but might it be possible that he is not part of the root group? And therefore cant open the Folder?

[parisi]

---

@Hermes wrote:

**EDIT

First of all, thank you for your assistance. I'm working on this issue now for quite a while and its driving me crazy.

Adding the Mapping in the other direction worked. Im not able to connect through NFS4.0 but I'm still not sure how it works and how it affects Folder/File creation.

---

Root will write as root, regardless of security style.

Here I have a UNIX-WIN name mapping that maps root to administrator:

::*> vserver name-mapping show -vserver DEMO -direction unix-win

Vserver: DEMO
Direction: unix-win
Position Hostname IP Address/Mask
-------- ---------------- ----------------
1 - - Pattern: root
Replacement: NTAP\\administrator

I can check that mapping and creds with:

::*> access-check authentication show-creds -vserver DEMO -unix-user-name root
(vserver services access-check authentication show-creds)

UNIX UID: root <> Windows User: NTAP\Administrator (Windows Domain User)

GID: daemon
Supplementary GIDs:
daemon
wheel

Primary Group SID: NTAP\DomainUsers (Windows Domain group)

Windows Membership:
NTAP\Group Policy Creator Owners (Windows Domain group)
NTAP\Domain Admins (Windows Domain group)
NTAP\DomainUsers (Windows Domain group)
NTAP\ProfGroup (Windows Domain group)
NTAP\Enterprise Admins (Windows Domain group)
NTAP\Schema Admins (Windows Domain group)
NTAP\Denied RODC Password Replication Group (Windows Alias)
NTAP\local-group.ntap (Windows Alias)
Service asserted identity (Windows Well known group)
BUILTIN\Administrators (Windows Alias)
BUILTIN\Users (Windows Alias)
User is also a member of Everyone, Authenticated Users, and Network Users

Privileges (0x22b7):
SeBackupPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege
SeSecurityPrivilege
SeChangeNotifyPrivilege

I mount a volume with NTFS and UNIX style qtrees:

demo:/home on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,local_lock=none,addr=x.x.x.x)

Here are the qtrees:

::*> qtree show -vserver DEMO -volume home
Vserver Volume Qtree Style Oplocks Status
---------- ------------- ------------ ------------ --------- --------
DEMO home "" unix enable normal
DEMO home dynamicuid unix enable normal
DEMO home ftp unix enable normal
DEMO home ftpuser ntfs enable normal
DEMO home git unix enable normal
DEMO home mtuser ntfs enable normal
DEMO home oracle unix enable normal
DEMO home prof1 unix enable normal
DEMO home root unix enable normal
DEMO home student1 unix enable normal
DEMO home student2 unix enable normal
11 entries were displayed.

When I write to the UNIX style qtree, root it root:

# cd /mnt
# cd prof1
# touch rootfile
# ls -la | grep rootfile
-rw-r--r-- 1 root root 0 Aug 6 10:03 rootfile

When I write to the NTFS qtree as root, root is root (though the group is daemon):

# cd /home/mtuser
[root@centos7 mtuser]# touch rootfile
[root@centos7 mtuser]# ls -la | grep rootfile
-rwxrwxrwx 1 root daemon 0 Aug 6 10:05 rootfile

Daemon is the group because it's what ONTAP sees as the primary group. (see the show-creds output above)

Daemon in ONTAP is 1, but is 2 on my client. But because NFSv4.x uses name strings, it's using daemon@NTAP.LOCAL as the group, rather than the numeric.

::*> unix-group show -vserver DEMO -name daemon

Vserver: DEMO
Group Name: daemon
Group ID: 1
Users: -



# ls -lan | grep rootfile
-rwxrwxrwx 1 0 2 0 Aug 6 10:05 rootfile


# getent group daemon
daemon:x:2: