Sun Storage 7410 Unified Storage System
 
Sun Storage 7310 Unified Storage System
 
Sun ZFS Storage 7120
 
Sun ZFS Storage 7420
 
Sun Storage 7110 Unified Storage System
 
Sun ZFS Storage 7320
 
Sun Storage 7210 Unified Storage System
 

PLA-Support>Sun Systems>DISK>NAS>SN-DK: 7xxx NAS
 
.Old GCS Categories>Sun Microsystems>Storage - Disk>Unified Storage
 

In this Document

Purpose

Troubleshooting Steps

1 - Understand the purpose of the identity mapping service.

2 - Understand the identity mapping policies and ensure that the technical requirements are met.

3 - Develop a strategy for which security model will be used

4 - If using IDMU, check for these known issues.

5 - Verify name services.

6 - NFSv4 users cannot access files written by Windows clients.

7 - Windows users lack write permissions to files which have had the permissions (or the files themselves) written by NFSv3.

8 - Collect data and contact Oracle ZFSSA Support

References

Applies to:

Purpose

This document provides a procedure to resolve problems with the ZFS Storage Appliance identity mapping service and related issues with sharing files between Windows and UNIX. This document should be used to troubleshoot issues with identity mapping and cross-platform file sharing. 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.

Troubleshooting Steps

1 - Understand the purpose of the identity mapping service.

Identity mapping creates an equivalence between particular SMB (Windows) and NFS (UNIX) user and group accounts. This allows a user from one platform to maintain ownership of files and directories on both platforms so that any permissions that user has on one platform, apply to the other.
In the absence of specific user maps, SMB users and NFS users, even those with the same account name, will be treated as separate entities. If this is acceptable, and there's no need for file and directory ownership to carry over from one platform to the other, then the default idmap configuration with no rules is perfectly acceptable.

2 - Understand the identity mapping policies and ensure that the technical requirements are met.

Generally, both Active Directory and a UNIX naming service are required for identity mapping to function correctly.
<Document:1402483.1> describes the descriptions and requirements for each of the identity mapping modes.

3 - Develop a strategy for which security model will be used

To some extent, you must choose between the full capabilities of the ZFS ACL model, or backwards compatibility with traditional UNIX permissions.
<Document: 1428773.1> provides an introduction to these issues and some examples of putting them into practice.

4 - If using IDMU, check for these known issues.

IDMU is the identity mapping service provided with recent versions of Windows Server.
<Document: 1347897.1> describes a known issue with this configuration when it has not been correctly configured to provide UNIX naming services for the ZFSSA.

5 - Verify name services.

<Document: 1402596.1> gives instructions on how to verify the UNIX and AD name services and generally troubleshoot mapping issues.

6 - NFSv4 users cannot access files written by Windows clients.

In order for NFSv4 users to be able to access files and directories on the ZFSSA, it must be able to resolve all the users present in the ACL.
<Document 1403050.1> provides details on checking for this case and resolving the issue if necessary.

7 - Windows users lack write permissions to files which have had the permissions (or the files themselves) written by NFSv3.

The ZFS Storage Appliance is designed to apply permissions seamlessly from Windows to UNIX and vice-versa. For example, with identity mapping configured, setting a file read/write for the owner and group on UNIX should result in the file being read/write for the owner and group when the same file is accessed from Windows.
On ZFSSA system software versions prior to 2010.Q3.3.4, there were some exceptions to this where the opposite platform didn't have the expected permissions. The most common case is Windows users other than the owner being unable to write. Though these issues have been corrected in the latest system software release, data which was written with older releases could still behave this way.
<Document 1428783.1> describes how to identify and correct the issue (by rewriting permissions from either platform).

8 - Collect data and contact Oracle ZFSSA Support

At this point, if the problem has still not been resolved with the troubleshooting steps above, then raising a support case with Oracle Support is recommended. Having the following data will help to expedite a solution:

• A ZFSSA support bundle. See <Document 1019887.1>
• File and directory permissions from the command line. In Windows, use 'cacls' in a DOS Window. In UNIX, use the ls command (-V and -Vd for Solaris, equivalents for other UNIX OS)
• 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.

Back to <Document 1416406.1> ZFS Storage Appliances Troubleshooting Resource Center.

References

This solution has no attachment