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 0.0.0.0 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 documentation : The 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.
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:
::*> 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=10.193.67.225,local_lock=none,addr=10.193.67.237)
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
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 01 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.