Re: NFSv4 without Kerberos and permissions
On 10/14/2017 3:39 PM, Elena evlt wrote:
perhaps value defaults of nfs in ubuntu and debian are different and
perhaps nfs versions are different and any of these paremeters aren't
recognized in the host client.
2017-10-14 21:28 GMT+02:00 John Ratliff <email@example.com
I recently set up an NFS v4 server on debian stretch. If I use a
debian client to mount the share, everything works fine. However, if
I use a CentOS or a Ubuntu client, the permissions don't work.
I have synchronized the group ids manually, and that's the only
permissions I'm interested in.
I have a directory structure like this:
/export/ssl/wildcard is chmod 2750 with root:ssl-cert as its owner.
root user is uid 0, ssl-cert is gid 555.
My exports file looks like this:
There is no firewall on the server. iptables is wide open. Server is
10.77.9.188 and client is 10.77.9.189. hosts.allow has ALL:ALL on
the last line.
I have no trouble mounting the share on the client. But a member of
the ssl-cert group (again, it IS GID 555 -- I made the group
manually to ensure this) CANNOT enter the directory. They cannot
read files in the directory. They cannot do anything with the share.
I have this trouble with Ubuntu 14.04, Ubuntu 16.04, and CentOS 7. I
do not have any issues with Debian 8 or Debian 9 clients.
/etc/default/nfs-kernel-server is stock; no changes.
I have this problem with NFSv4 servers on Debian 8 and Debian 9.
If I run the NFS server on Ubuntu 16.04, I can access it fine from
Ubuntu clients and CentOS clients, but Debian clients have the same
What am I missing? What can I do to further troubleshoot this? Is
there any way to determine what mapping it THINKS is occurring?
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.