Mixed protocol environments can be complex to manage but if you have a required use case it’s better to setup it properly ahead of time than mid-production use.

There are complexities when working with a mixed protocol environment which is a result of how Windows and *nix systems handle security at the core of their respective operating systems. *nix platforms handles permissions by using permission bits and Windows uses Access Control Lists (ACL). Ownership of a file is either defined by a User ID (UID) in the Unix world or a Security ID (SID) in Windows.

Fundamentally, *nix and Windows platforms handles files, permissions and sharing completely differently and this introduces new complexities because of this business requirement. It is my personal advice, try to avoid running a mixed protocol environment if possible. If a there is a requirement that mandates this need, then design and plan accordingly to prevent future headaches down the road.

This article is not a how-to guide on how to implement a mixed protocol environment since each implementation is unique since there is a complexity reason for driving to use the mixed protocol environment to begin with. Use the following as things to understand and to take in account BEFORE you implement a mixed protocol environment.

This article is a cliff-notes version of the following EMC documents, Multiprotocol Environment Guide and the User Mapper Guide.

It is important that the sections below are completely understood a head of time for accurate planning of multiprotocol environment. If a change is required after the filesystem is already in production, there is no easy way to change these settings without creating another filesystem and rsync’ing/robocopy’ing the data between filesystems.

Understanding CIFS and Unix Permissions

CIFS

• Access Control Lists
• SID Ownership
• Username Passwords

*nix

• Permission Bits
• UID & GID Ownership Bits
• IP Address Access

Access-checking policy	Description
Native (default)	Access to a file or directory through NFS or UNIX authenticated FTP is granted only if the UNIX permissions on the file or directory allow it. Access through CIFS or Windows authenticated FTP is granted only if the Windows permissions on the file or directory allow it. ACL and UNIX permissions are maintained for every file and directory. A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS.
NT	Access to a file or directory through NFS or UNIX authenticated FTP is granted only if the UNIX and Windows permissions allow it. Access through CIFS or Windows authenticated FTP is granted only if the Windows permissions allow it (the UNIX permissions do not have any effect). ACL and UNIX permissions are maintained for every file and directory. A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS.
UNIX	Access to a file or directory through NFS or UNIX authenticated FTP is granted only if the UNIX permissions allow it (the Windows permissions do not have any effect). Access through CIFS or Windows authenticated FTP is granted only if the UNIX and Windows permissions on the file or directory allow it. ACL and UNIX permissions are maintained for every file and directory. A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS.
SECURE	Provides the greatest security across CIFS and NFS. Access to a file or directory through either NFS or FTP or CIFS is granted only if the UNIX and Windows permissions on the file or directory allow it. ACL and UNIX permissions are maintained for every file and directory. A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS.
MIXED	Access to a file or directory through either NFS or FTP or CIFS is always determined by the ACL. ACL and UNIX permissions are maintained for every file and directory. ACLs for files and directories are created from the protocol that last set or changed the permissions. For example, if an NFS client sets or changes permissions on a file or directory, the ACL is rebuilt based on the UNIX mode bits. If a CIFS client sets or changes permissions on a file or directory, the ACL is built based on the standard Windows permissions. In all cases, the ACL determines file and directory access regardless of whether the client is using the NFS, CIFS or FTP protocol. ACL permissions are more granular than UNIX mode bits, consequently not all permissions set in an ACL can be translated to UNIX mode bits. In some cases, the mode bits might show more permissions than a user actually has
MIXED_COMPAT	Access to a file or directory through NFS or FTP or CIFS is determined by which protocol (NFS or CIFS) last set or modified the permissions. ACL and UNIX permissions are maintained for every file and directory. If the permissions of a file or directory are set or changed from a CIFS client, then access is determined by the ACL (EXPLICIT ACL). UNIX mode bits are generated based on the ACL but are not used for access checking. If the permissions of a file or directory are set or changed from a UNIX client, then UNIX mode bits dictate access. An ACL is still created but is not used for access checking. ACL permissions are more granular than UNIX mode bits, consequently not all permissions set in an ACL can be translated to UNIX mode bits. In some cases, the mode bits might show more permissions than a user actually has.

Understand Permission Translations

ACL to Unix Rights

Unix to ACL Rights

Understand your Inheritance

NATIVE, UNIX, NT, and SECURE

MIXED and MIXED_COMPAT

You can find this information and a wealth of other information in EMC’s Multiprotocol Environment Guide and User Mapper Guide.

Other Observed Notes:

• Taking ownership from Windows Permissions/ACL will change the underlying UID/GID owner even though it is stated otherwise in Native Mode.