[Freeipa-users] Can mount NFS, but user only gets the permission question marks

[Kees Bakker]

On 21-02-17 19:49, Brendan Kearney wrote:
> On 02/21/2017 10:57 AM, Kees Bakker wrote:
>> Hey,
>>
>> Maybe one of the NFS users on this list could give me a hint what
>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.
>>
>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm
>> guessing that setting up Kerberos principal was done correctly.
>>
>> However, only root can actually access the mounted contents. Any other user
>> only sees question marks as shown below.
>>
>> The mount command is simple.
>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome
>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'
>>
>> On the server side /etc/exports looks like this.
>> /home        *(rw,sync,sec=krb5i,no_subtree_check)
>>
>> $ sudo mount |grep nfs
>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)
>>
>> $ sudo ls -ld /nfshome
>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
>> $ sudo ls -l /nfshome
>> total 0
>> drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb
>>
>> $ ls -l /nfshome
>> ls: cannot access '/nfshome': Permission denied
>> $ ls -l / | grep nfshome
>> ls: cannot access '/nfshome': Permission denied
>> d?????????   ? ?    ?       ?            ? nfshome
>>
> sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share.  from the looks of things, the user did not authenticate, and that is why the permissions are question marks.  check the kerberos tickets that the user has (klist output).  Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client)

Thanks for the reply.

In this case the user _is_ authenticated.
keesb at client1:~$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: keesb at EXAMPLE.COM

Valid starting     Expires            Service principal
22-02-17 09:20:30  23-02-17 09:20:25  krbtgt/EXAMPLE.COM at EXAMPLE.COM

What other grants could be needed? HBAC Rules?

Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it
doesn't help to get access for the user.)

Furthermore, I'm guessing that the host principle which I got after ipa-client-install is
good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I
did not do.)
# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/client1.example.com at EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   1 host/client1.example.com at EXAMPLE.COM (aes128-cts-hmac-sha1-96)



[1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA
[2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/
-- 
Kees