[OmniOS-discuss] NFSv4 id mapping only working on client but not server?

[John Klimek]

Paul, thanks!  You understand exactly what I'm asking and what my problem
is.

Something seems to be going wrong (or incorrectly configured) with the NFS
id mapping services on my Linux client or OmniOS server.

I've setup the nfsmapid_domain and I believe it's working because before
configuring it, everything was showing as nobody/nobody, but afterwards it
shows the correct names.  (on the client)  I can also see in the client log
and it's correctly mapping user at domain.com in the Linux rpc.idmapd domain.

The problem is that when I create a file on the client, the server (OmniOS)
is showing the UID of the user that created the file instead of mapping it
using the name to the local UID.

It looks like I can avoid the problem if I synchronize UIDs and GIDs across
all servers (it's a small home network so it's not a big problem and I'm
not using LDAP or NIS), but NFSv4 was supposed to avoid this problem by
using name mapping so you didn't have to synchronize UIDs/GIDs.



On Thu, Dec 4, 2014 at 3:59 PM, Paul B. Henson <henson at acm.org> wrote:

> > From: Michael Rasmussen
> > Sent: Thursday, December 04, 2014 11:11 AM
> >
> > Yes, because you want to avoid Omnios presents ACL which is incompatible
> > with Linux ACL.
>
> I don't believe the ACL has anything to do with NFSv4 id mapping? And a ZFS
> ACL presented over NFSv4 is perfectly compatible with Linux. It's not a
> Linux POSIX ACL, and cannot be manipulated with getfacl/setfacl, you need
> to
> use the nfs4 ACL tools, but it works fine.
>
> > http://forum.proxmox.com/threads/15793-CT-creation-on-NFS-
> > Share?p=81530#post81530
>
> In that thread, the user fails to chmod via NFS:
>
> chmod: changing permissions of `/mnt/pve/proxCT/private/108.tmp': Operation
> not permitted
>
> The root cause of which was a setting of restricted for aclmode:
>
> vdev1/proxCT aclmode             restricted
> local
>
> Per the man page "An aclmode property of restricted will cause the chmod(2)
> operation to return an error when used on any file or directory which has a
> non-trivial ACL whose entries can not be represented by a mode."
>
> The user could have set the inherited ACL on the initial filesystem to a
> trivial ACL, in which case chmod would've worked fine over NFS.
>
> In any case, I don't see anything in that thread that seems relevant to
> NFSv4 id mapping, which unless I misunderstand is the problem the OP is
> trying to resolve.
>
> On that subject, NFSv4 id mapping seems to be working fine for me between
> an
> omnios client and server. On the server, the file system is mounted as:
>
> /export/user/henson on export/user/henson
> read/write/nosetuid/nodevices/nonbmand/exec/xattr/atime/dev=2c5025c
>
> And exported as:
>
> /export/user/henson     -       nfs     nosuid,sec=krb5i,sec=krb5p
>
> with the domain set:
>
> $ sharectl get -p nfsmapid_domain nfs
> nfsmapid_domain=csupomona.edu
>
> if I create a file on the server, it has the correct ownership:
>
> $ touch test_server
> $ ls -l test_server
> -rw-r--r--+ 1 henson csupomona 0 Dec  4 12:50 test_server
>
> on the client, the NFS export is mounted as:
>
> /mnt on files-www.csupomona.edu:/export/user/henson
> remote/read/write/setuid/devices/sec=krb5p/xattr/dev=85c0008 on Thu Dec  4
> 12:50:01 2014
>
> the client has the same domain:
>
> $ sharectl get -p nfsmapid_domain nfs
> nfsmapid_domain=csupomona.edu
>
> The file created on the server shows up with the correct ownership:
>
> $ ls -l test_server
> -rw-r--r--+ 1 henson csupomona 0 Dec  4 12:50 test_server
>
> A file created on the client has the correct ownership:
>
> $ touch test_client
> $ ls -l test_client
> -rw-r--r--+ 1 henson csupomona 0 Dec  4 12:52 test_client
>
> And viewed back on the server, still correct:
>
> $ ls -l test_client
> -rw-r--r--+ 1 henson csupomona 0 Dec  4 12:52 test_client
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20141205/d2a79d69/attachment-0001.html>