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

[Ian Kaufman]

As far as I recall, AUTH_UNIX (aka AUTH_SYS) uses RPC, and RPC has not
been augmented to support NFSv4 yet.

>From an old thread in the OpenSolaris boards:
-------------------------------------
Note also, that although NFSv4 uses strings for uid/gid/domain, the
underlying RPC layer uses the same authentication credentials as in
previous NFS versions and other RPC programs.

Since it's the RPC authentication that is used to control access, etc,
don't expect too much from the NFSv4 name/id mapping. It's useful for ls
-l listings, etc, but not for authentication.
-------------------------------------


On Fri, Dec 5, 2014 at 5:32 AM, John Klimek <jklimek at gmail.com> wrote:
> 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
>>
>>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu