[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <john@bluemarble.net <mailto:john@bluemarble.net>>:

    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 and client is 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-common has

    /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.

Reply to: