Oracle ZFS Storage: NFS Version 4 Will Not Allow Root To "chown Oracle Filename" On Any Share Mounted From Appliance

Asset ID:	1-72-1664105.1
Update Date:	2018-02-08
Keywords:

Solution Type Problem Resolution Sure

Solution 1664105.1 : Oracle ZFS Storage: NFS Version 4 Will Not Allow Root To "chown Oracle Filename" On Any Share Mounted From Appliance

Applies to:

Oracle ZFS Storage ZS3-4 - Version All Versions to All Versions [Release All Releases]
Oracle ZFS Storage ZS3-2 - Version All Versions to All Versions [Release All Releases]
Sun ZFS Storage 7120 - Version All Versions to All Versions [Release All Releases]
Sun ZFS Storage 7420 - Version All Versions to All Versions [Release All Releases]
Sun ZFS Storage 7320 - Version All Versions to All Versions [Release All Releases]
7000 Appliance OS (Fishworks)

Symptoms

I have created a share on 2 different ZFS appliances. One running 2013.06.05.1.6,1-1.1 and One running 1013.06.05.1.1,1-1.2
Both exhibit the same behavior.

root@dc1n01db01:/zext-work# chown oracle anyfile
chown: anyfile: Permission denied
root@dc1n01db01:/zext-work#

When a share is created it will not allow root to chown to another user. Example “chown oracle testfile”

Some things tried:

-works without issue with NFS Version 3

-oracle user does exist on client
-all permissions have been set to rwx on the share owner,group,other

-"root access" has been set on protocol exception
-Network has been verified as correct network ip and netmask

-Various combinations of ACL settings have been tried, Inherit, don’t inherit, etc

- We have started with fresh share after most changes to make sure there are no residual settings from previous tries.

-DNS is working , used getent host “our host” resolves fine. Reverse lookup, works fine.

It simply appears that NFS Version 4 just doesn’t work for chown operations on the client. when mounted from our ZS3 appliance

Cause

As noted in <Document:1439378.1>, the preferred solution is that a common set of LDAP or NIS servers be configured for both client and server. However, in cases where the customer is unable to do so, this may serve as a partial workaround.

In this customer case they have very few users to administer so this solution was effective.

Solution

For this to work you need to make sure the following is correct on the client and ZFS SA server

1) Must be in DNS reverse and forward lookup
2) The /var/run/nfs4_domain must match between client and ZFS SA appliance
3) From the solaris client you can sharectl get -p nfsmapid_domain nfs Use "sharectl set -p nfsmapid_domain=”......" nfs (for Solaris 11)

For Solaris 10 please see doc 1006669.1

4) From the BUI of the appliance you need to click on the NFS service and set " Custom NFSv4 identity domain "

5) As a workaround we created the user on the appliance, because the customer did not want to configure NIS or LDAP.

Note - this did work but is not really recommended as a solution..

References

<NOTE:1402483.1> - Sun Storage 7000 Unified Storage System: Identity mapping policies and requirements
<NOTE:1409693.1> - Sun Storage 7000 Unified Storage System: NFSv4 clients cannot mount shares if NFSv4 identity domains do not match
<NOTE:1006669.1> - NFS version 4 mounted files and/or directory owner or group shows as nobody

Attachments

This solution has no attachment