Sun ZFS Storage 7420
 
Sun Storage 7110 Unified Storage System
 
Exalogic Elastic Cloud X5-2 Hardware
 
Oracle SuperCluster M7 Hardware
 
Sun Storage 7210 Unified Storage System
 
Sun Storage 7410 Unified Storage System
 
Sun ZFS Storage 7120
 
Sun Storage 7310 Unified Storage System
 
Sun ZFS Storage 7320
 
Oracle ZFS Storage ZS3-2
 

PLA-Support>Sun Systems>DISK>ZFS Storage>SN-DK: 7xxx NAS
 

In this Document

Purpose

Troubleshooting Steps

References

Applies to:

Purpose

This document provides a procedure to resolve problems with NFS file and directory permissions/security on the ZFS Storage Appliance.

Troubleshooting Steps

Steps to Follow

This document should be used to troubleshoot issues accessing files and directories over NFS mounts. Each of the following steps will provide instructions and/or a link to a document, to check for issues and provide corrective action as necessary.

Step 1 - Understand how ACLs and traditional UNIX permissions inter operate

See Document 1428773.1 for tips on configuring security in an environment where both traditional NFSv3 permissions and NFSv4 ACL permissions.

ACL permissions allow you to go beyond the standard user/group/world security entities and configure files and directories with named users and inheritance bits, at the cost of some compatibility with traditional permissions.

Step 2 - Understand how file and directory permission inheritance works.

ACL security allows you to specify exactly what permissions should be inherited to newly created files and directories. This document 1439307.1 explains how the ACL inheritance bits operate.

Step 3 - Check your NFSv4 Identity Domain configuration

A common problem with NFSv4 clients is that the NFSV4 identity domain on the client does not match that of the server. Because NFSv4 users are presented in a user@domain format, an incorrect identity domain can result in limited or no access to files or mount points. See Document 1409693.1 for instructions on how to verify that these match.

Step 4 - Ensure that client and server are using a common database to resolve uids and gids

It is strongly recommended to use a naming service, such as LDAP and NIS, and to ensure that both clients and server (ZFSSA/ZS-3) are using the same service. This allows them to agree on which uid or gid a particular name refers to, and to use those names for security assignments. NFSv4 is much more sensitive to this, as it uses names over the wire rather than numeric uids/gids. You can work around this sometimes on NFSv3 by using a numeric ID, but NFSv4 will fail security and ownership changes to or from names that it cannot resolve.

Step 5 - Check for correct configuration of NFS Exceptions (A.K.A. root squash)

By default, root users on client systems are not given unrestricted access to filesystems on the ZFS Storage Appliance. See Document 1439295.1 for instructions on how to create NFS Exceptions that allow NFS clients to access the ZFSSA as root.

Step 6 - Known issue with chown for non-root users

By default, only root is able to change ownership of files via NFS. Document  1439387.1 explains how to change this if necessary.

Step 7 - Know issue Users report performance issues or NFS outages  from client mounted share side and  identified NFS drops.

Solution: NFS service on peer node were in disable state and need to be enabled.
After enabling the NFS service on the peer node. NFS mounts resumed on both the nodes immediately.

Step 8 - RedHat Linux 6.3 - chown fails with invalid argument on nfsv4 mounted file systems

This is not related to any problem on the appliance. Upgrade of RedHat version to 6.4 for the fix to RedHat bug 150526 (NFS write/chown fails) resolves this issue.

Discovered in SR 3-7415670651

Step 9 - Collect data and contact Oracle ZFSSA Support

At this point, if you not been able to resolve the issue with the troubleshooting steps above, a support case is recommended. Having the following data (as available) will help us to expedite a solution:

• A ZFSSA support bundle. See Document 1019887.1
• File and directory permissions from the command line. In UNIX, use the ls command (-V and -Vd for Solaris, equivalents for other UNIX OS). If there's a file operation involved, collect this data both before and after the operation.
• Steps to reproduce the problem.
• If possible, a network capture of the failed attempt to access the file. This should be run from the client, and should begin before the drive is mounted or mapped. See Document 1398376.1 for details on how to collect a network capture.

References

This solution has no attachment