ONTAP Discussions

Getting into NFS4 and Kerberos : chown files and folders


Hello all,

Following the excellent guide TR-4616 by @parisi we managed to configure a test environment for NFS4 + Kerberos

We have :

  • Active Directory KDC (Windows 2016) renamed "MY.REALM" in the next few lines
  • Netapp 9.8P4 SVM (SVMP_NFS4) with configured REALM interface, NFS/ SPN, name-mapping, etc. as described in TR-4616
  • volume (unix security-style) exported via default export-policy allowing every access for krb5* protocols
  • Debian 10 client joined to the domain with a valid ticket (klist -ke with good SPN, aes ciphers, etc.)

So far, we managed to mount an NFS4 export through fstab file using the machine Kerberos ticket.


Navigating through the mounted directory as (local) root user is ok, can mkdir/touch/rmdir/etc.


Now we would like to interact with ActiveDirectory Users.

# id myUser@MY.REALM  

gives the identity of myUser in AD mapped by idmapd

# su myUser@MY.REALM

is also ok.


I would like to simply chown a folder in my mounted volume to myUser@MY.REALM but so far It is not possible (invalid argument error)


AFAIUnderstand NFS4/Kerberos (wish me luck) , the Debian Client AND the Netapp System needs to know about myUser@MY.REALM to give him access to ressources. (chown included I suppose ?)


I tried to create a Netapp local unix-user myUser and added a krb-unix name-mapping rule to transform myUser@MY.REALM to myUser but It does not seem to change anything, still unable to chown.


Seems that there is something I do not understand in the NFS4/Kerberos philosophy ! Any help/hints/URLs appreciated 


Thanks, by advance.



PS : no errors shown in event log show, but 2 stranges lines in journalctl when I try to chown

jun 08 19:16:28 docnfs4 nfsidmap[834]: key: 0x289f38a4 type: gid value: daemon@MY.REALM timeout 600

jun 08 19:16:28 docnfs4 nfsidmap[835]: key: 0x10913ca1 type: user value: 1469534676 timeout 600



I don't see the "kinit" by the user in question. Did you run kinit?


One thing I had to do in my lab was set the chown mode to unrestricted on the SVM to allow chown by the user.


::*> nfs server show -vserver DEMO -fields chown-mode
vserver chown-mode
------- -----------------
DEMO use_export_policy


::*> nfs modify -vserver DEMO -chown-mode unrestricted


Once I did that, my results went from this:


sh-4.2$ chown student1 newdir
chown: changing ownership of ‘newdir’: Operation not permitted


To this:


sh-4.2$ id
uid=1102(prof1) gid=10002(ProfGroup) groups=10002(ProfGroup),48(apache-group),1202(group2),1203(group3),10000(Domain Users)

sh-4.2$ chown student1 newdir

sh-4.2$ ls -la | grep newdir
drwxrwxrwx 2 student1 ProfGroup 4096 Jun 8 14:03 newdir






Thanks for you work on TR and your reply here !


In my understanding (but I obviously could be wrong...) kinit was not yet necessary at this point !


  • Connected as local root on my machine
  • Having a machine Kerberos ticket (klist -ke) MYMACHINE$@MY.REALM
  • Having  a name-mapping rule to transform (.+)\$@MY.REALM  to root
  • Having an export-policy allowing with KRB5* and Super-User Access

I should be "root" on my volume and able to do anything I want ? (mkdir/rmdir/touch/cat/.....)


The chown-mode in my vserver is set to use_export_policy

The chown-mode in my export-policy is set to restricted


According to the documentationThe setting can either allow only the root (with value restricted) or all users (with value unrestricted) to change file ownership provided the on-disk permissions allow the operation.


In my example, the volume could host home directories. root should be able to chown directories to users, but not all users ? Let's test.


MyCluster::*> export-policy rule modify -vserver SVM_NFS4 -policyname default -ruleindex 1 -chown-mode unrestricted 


But still "Invalid argument"  when trying to chown a file/folder.


If I su as myUser@MY.REALM and kinit.

I can create dirs/files on the mounted volume, but everything file/dir is mapped to nobody/???  :

drwxr-xr-x 2 65534 4294967294 4096 juin   9 10:11 test5


I might be missing something in the NFS4 design...





If you are using "root" then no need for kinit, as the krb-unix mapping handles that.


But your original question was about a specific user - for that, you'd need to kinit. And there is a krb-unix mapping for USER@DOMAIN.COM to UNIX user USER, but that doesn't require a name mapping rule, provided ONTAP can find the UNIX user named "USER" in name services.


In my lab, as root, I can chown with the restricted chown-mode set without needing to kinit:


::*> nfs show -vserver DEMO -fields chown-mode
vserver chown-mode
------- -----------------
DEMO use_export_policy


::*> export-policy rule show -vserver DEMO -policyname home -fields chown-mode
vserver policyname ruleindex chown-mode
------- ---------- --------- ----------
DEMO home 1 restricted


Here's the Kerberos mount:

[root@centos7 /]# mount -o sec=krb5 demo:/home /mnt/home
[root@centos7 /]# mount | grep home
auto.homedir on /home type autofs (rw,relatime,fd=17,pgrp=1157,timeout=50,minproto=5,maxproto=5,indirect,pipe_ino=971)
demo:/home on /mnt/home type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=,local_lock=none,addr=


Note that when I create a new file, the owner is root. In your case, the owner is nobody, which is likely why it's failing for you... root is not root there.

[root@centos7 /]# cd /mnt/home

[root@centos7 home]# touch newfile
[root@centos7 home]# ls -la | grep newfile
-rw-r--r-- 1 root daemon 0 Jun 9 13:04 newfile


And I can chown that file as root with no issues:

[root@centos7 home]# chown prof1 newfile
[root@centos7 home]# ls -la | grep newfile
-rw-r--r-- 1 prof1 daemon 0 Jun 9 13:04 newfile


As a regular user, I can't (because of the restricted chown mode - aka, root-only-chown):

# su prof1
sh-4.2$ kinit
Password for prof1@NTAP.LOCAL:
sh-4.2$ cd ~

sh-4.2$ mkdir newdir2
sh-4.2$ ls -la | grep newdir2
drwxr-xr-x 2 prof1 ProfGroup 4096 Jun 9 13:09 newdir2
sh-4.2$ chown student1 newdir2
chown: changing ownership of ‘newdir2’: Operation not permitted


When I set the export policy to allow it, I can chown with a regular user:

::*> export-policy rule modify -vserver DEMO -policyname home -ruleindex 1 -chown-mode unrestricted


sh-4.2$ chown student1 newdir2

sh-4.2$ ls -la | grep newdir2
drwxr-xr-x 2 student1 ProfGroup 4096 Jun 9 13:09 newdir2


In a homedir setting, you can create a qtree per user and apply individual export policies to those qtrees if you want different levels of access for chown, control for different clients, etc.


You'd need to look into why root is writing files as "nobody" here; I suspect it's due to how you've set up your krb-unix name mapping or you've set "superuser" to "none" in the export-policy rule and it's getting squashed to the user set in -anon (which is 65534 by default).




Sorry If was not very clear about my original question. 


I need the local root user to chown a folder to a Kerberos User. Files created by root are mapped root:daemon


root@docnfs4:~# ll /media/testnfs/

drwxr-xr-x 2 root   daemon     4096 juin   8 01:21 test


(with ll -n)

drwxr-xr-x 2     0          1 4096 juin   8 01:21 test


And If "su" as myUser@MY.REALM and then kinit and then create a folder, I get nobody:strange  :

drwxr-xr-x 2 65534 4294967294 4096 juin   9 10:11 test5




In your lab, just to be sure I understand it : prof1 is a local centOS user ? prof1@NTAP.LOCAL is also a Kerberos user ? And I suppose you have a krb-unix mapping rule to transform prof1@NTAP.LOCAL to prof1 ? And that you have a local unix-user defined in your SVM named prof1 ? is your local prof1 uid aligned with SVM unix-user prof1 uid ?


Thanks for your time, I will try to deploy a centOS client in parallel.




- prof1 is a UNIX user in AD LDAP

- prof1 is also a Windows user in AD (on the same user principal)

- prof1@ntap.local is, by nature if AD, the Kerberos UPN

- I have no krb-unix name mapping because the Windows and UNIX user that ONTAP finds are the same names, so it maps implicitly 

- you could create a local UNIX user with the same name in lieu of LDAP

- krb-unix name mapping rules are only needed if the UPN user name and UNIX user name are not identical. (Ie, Windows user john.smith and UNIX name jsmith)


Hello there,

I managed to make Debian and CentOS show correct informations. (SSSD and idmapd configuration files)


If I understand your reply correctly, I need to add an AD/LDAP configuration in the ns-switch/passwd database ?

This way, myUser@MY.REALM will be recognized.


As a workaround, I can create a local UNIX user named myUser !


Starts to make sense 😄 (I hope...)





AD/LDAP isn't required, but it makes things simpler/more streamlined. Local users should work, too, but if you have a lot of users, you don't want to be creating a ton of