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

[Brendan Kearney]

On 03/02/2017 05:40 AM, Kees Bakker wrote:
> On 24-02-17 14:38, Brendan Kearney wrote:
>> On 02/24/2017 03:33 AM, Kees Bakker wrote:
>>> On 23-02-17 15:39, Brendan Kearney wrote:
>>>> On 02/23/2017 09:11 AM, Kees Bakker wrote:
>>>>> On 23-02-17 13:51, Brendan Kearney wrote:
>>>>>> On 02/23/2017 07:32 AM, Kees Bakker wrote:
>>>>>>> On 22-02-17 17:33, Brendan Kearney wrote:
>>>>>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote:
>>>>>>>>> On 22-02-17 14:05, Brendan Kearney wrote:
>>>>>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote:
>>>>>>>>>>> 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
>>>>>>>>>>>>>
> [...]
>
> Continuing story...
>
> I've tried various things in the meantime. I've set up two test environments with virtual
> machines (virtualbox).
> * with Fedora 25; this works.
> * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks).
>
> I also looked at the verbose output of rpc.gssd, it gives
>
> ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection
does the actual error message say @REALM, or did you substitute that to 
obscure sensitive info?  if it does actually say @REALM, then you are 
missing a config directive somewhere, that specifies the kerberos realm.
> getting credentials for client with uid 60001 for server srv1.example.com
> getting credentials for client with uid 60001 for server srv1.example.com
> WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com
>
> But the user really did get a TGT.
>
> $ klist
> Ticket cache: KEYRING:persistent:60001:60001
> Default principal: keesb at EXAMPLE.COM
>
> Valid starting     Expires            Service principal
> 02-03-17 10:25:25  03-03-17 10:25:22  krbtgt/EXAMPLE.COM at EXAMPLE.COM
>
> So, still no solution for Ubuntu + freeipa + nfs.
>
> BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. However,
> there is only any output when root (uid 0) does a NFS directory lookup. When a regular
> user tries to stat the NFS directory it does not even get to the point where id mapping is
> done.