3

First off, please excuse me if my question isn't well formed, this is my first post on serverfault :)

I have successfully deployed LDAP and Kerberos authentication in a mixed Linux/Windows/Solaris network. I have CentOS 7 server serving NFS4 with krb5 security (no privacy/integrity, just authentication). I can successfully mount the shares on CentOS 6. However, when I mount the share on Solaris 10 (Oracle Solaris 10 9/10 s10s_u9wos_14a SPARC), I get some strange ACL-related error.

Output from mount:

/mnt/exporthome on nfsserver.example.com:/export/home remote/read/write/setuid/devices/sec=krb5/xattr/dev=5ec0004

I do have access, I can read the files:

$ ls /mnt/exporthome/testuser/
testfile1.txt textfile2.txt

However, I cannot read permissions/ACLs, instead I get:

$ ls -la /mnt/exporthome/testuser/
ls: can't read ACL on /mnt/exporthome/testuser/: Permission denied

nfs4_domain is correctly set on both client and user, and ID-mapping seems to work for the user:

$ getfacl /mnt/exporthome/testuser/

# file: /mnt/exporthome/testuser/
# owner: testuser
# group: testgroup
user::rwx
group::---              #effective:---
mask:rwx
other:---

I can see

the following message appears in the logs:

/usr/lib/nfs/nfsmapid[349]: [ID 300081 daemon.error] valid_domain: Invalid inbound domain name .

I've checked the code that generates the message, "inbound domain name" refers to the remote (i.e. server) nfs4 domain. I sniffed the traffic, and I see the server correctly sends fattr4_owner as "[email protected]". The problem appears to be with the reco_attr: ACL, where I have three ACEs.

The "Who" fields in the ACEs are: "OWNER@", "GROUP@" and "EVERYONE@", so my guess is that they cause the "invalid inbound domain name" error message.

OWNER@, GROUP@, and EVERYONE@ (among with several others) are specified with special meaning in the RFC that defines NFSv4 ACLs, and as I mentioned earlier, the other hosts accessing the NFS shares have no problem with them.

I've search Oracle's site, and the document these principals as "owner@", "group@", and "everyone@" in some of their NFSv4/ACL/ZFS articles.

I don't have access to Solaris NFS server, but my guess is that it sends the ACEs with these principals in lowercase, and the native Solaris 10 NFSv4 client cannot handle them in uppercase (as specified in the RFCs).

So my questions is, has anyone else tried similar deployment, and did they have the same results. It would be great if someone having working Solaris 10 NFSv4 client would check the principals in the ACL. Actually, at this point, any suggestion would be great.

Thanks in advance!

2
  • can be encoding problem between client and server. Solaris 10 expects ASCII in nfs domain: github.com/kofemann/opensolaris/blob/…
    – kofemann
    May 25, 2015 at 20:21
  • Checked, not an encoding issue (both server and client send/receive in ASCII, and the users are actually correctly mapped). It seems like I'm hitting a known bug: 6261858 ls(1) -l, getfacl(1), and setfacl(1) can return "Permission denied" due to "nobody" and ACLs The bug is fixed in later releases, so I will try to upgrade at some later point, and will report if this indeed was the problem. May 27, 2015 at 7:58

0

You must log in to answer this question.

Browse other questions tagged .