Permission denied on NFS4 share with Ubuntu 14.04 client

[John Ratliff]

On 10/13/2017 10:14 PM, Joseph Loo wrote:
> On 10/13/2017 06:15 PM, John Ratliff wrote:
>> I setup an NFS4 server on Debian 9. I have no issues with permissions on
>> other Debian clients I have tried (Jessie or Stretch Debian Versions).
>>
>> However, I have 3 Ubuntu 14.04 servers, and I always get permission
>> denied errors on these servers.
>>
>> I am not using Kerberos. Just plain IP based authentication.
>>
>> This is my entry on Ubuntu 14.04 fstab.
>>
>> nfs:/x/share /mnt/nfs        nfs4    ro,proto=tcp,sec=sys 0 0
>>
>> This is my exports file on Debian 9 server.
>>
>> /export 192.168.1.0/24(ro,fsid=0,no_subtree_check,sync)
>> /export/x/share
>> 192.168.1.0.0/24(ro,nohide,insecure,no_subtree_check,sec=sys)
>>
>> Permissions on directory
>>
>> /export/x/share 2750 (u+rwx g+rxs o-ALL)
>> Owner is root
>> Group is ssl-cert
>>
>> The group ID on Ubuntu 14.04 is 999
>> The group ID on Debian 9 is 999
>>
>> I made sure these were the same.
>>
>> $ ls -l
>> total 4
>> drwxr-s--- 2 root ssl-cert 4096 Oct 13 14:37 nfs
>>
>> $ cd nfs
>> -bash: cd: nfs: Permission denied
>>
>> $ groups
>> jratliff adm sudo staff ssl-cert qmail
>>
>> $ grep ssl-cert /etc/group
>> ssl-cert:x:999:jratliff
>>
>> I've restarted every service I can think of on both the client and
>> server. Then I rebooted them both, first the server then the client. No
>> change.
>>
> This is my exported directory file:
> /export	*(fsid=0,crossmnt,rw,root_squash,sync,no_subtree_check)
> /export/home0	192.168.20.0/8(rw,root_squash,sync,no_subtree_check)
> 127.0.0.0/8(rw,root_squash,sync,no_subtree_check)
> 
> I dn't know if you want your files to be rw but your setup will not
> allow it. The 127.0.0.0/8 allows local mounts
> 
> execute showmount command to show the exported directory
> 

After much googling, I have found the answer.

The Debian NFS server, by default, uses --manage-gids in the 
RPCMOUNTDOPTS in /etc/default/nfs-kernel-server. I guess I never looked 
very hard at that option, but what it means is that group membership is 
checked on the server, not trusted from the client. This is a good thing 
overall; it improves security and overcomes a limitation of the NFS 
protocol (16 group count).

In my case, the user on the client I was testing was UID 1003, which on 
the server he was UID 1000. So they both had the group, but UID 1003 on 
the server did not have the group, because that user did not exist. 
Therefore, permission denied.

Although it's not the best solution from a security standpoint, I'm 
going to disable the manage-gids option for now and limit access by 
hosts.allow and the firewall.

Thanks very much to 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1454112 this post.