How to manage permissions on a StorNext filesystem

Situation:

In a shared environment as in a Linux based NAS, the permissions can be set/enforced via the exports file or the Samba configuration or even through yp (yellow pages aka NIS). Comparing it to a SAN based solution you will most likely run into permission issues which you haven’t experienced before. Before each client was writing into the shared volume and all the others could collaborate as expected and since you have a SAN, you face the problem that content created by client-A can’t be modified from client-B or others.

Cause:

Due to the nature of SAN solutions, every client sees the shared filesystem (volume) as a local disk because of the FC fabric underneath. This provides extreme fast access to the data for reads and write but has no rights management involved. StorNext which is the base layer for your MDC (MetaDataController) isn’t interested in dealing with permissions or any kind of rights management, hence while every client is the “owner” of this filesystem they don’t have any knowledge about those other clients.

Solution:

As mentioned, the underlying StorNext layer has a “don’t care” policy and if you read in the manuals that StorNext supports ACL (access control list), it’s a client mapping function on the server and filesystem itself.
To get around all this permission hassle you have basically 3 options to make your life easier again.

A) The big and may more expensive way is to have a Windows DC or a OS/X server which can act as a domain controller and support ACL. All clients would authenticate against that domain controller and the filesystem configuration can have ACL support enabled (not data destructive for a filesystem if enabled later). Least but not last, almost all Linux distributions support open LDAP server but you need a lot of expertise.
This is the most expensive option as it would require a dedicated server.

B) In case you have a Linux based server, you can setup and activate NIS (lot easier than LDAP). Also here you have to have the clients authenticate against this server. NIS is limited in the view of permission and not as granular as Windows DC or OS/X server but still a way to go. Only drawback on this might be the Windows world which can not native connect to a NIS server expect you have a Windows server which does come with NIS tools.

C) The most common way is to match IDs. This can be the UID (user ID) or the GID (group ID). Matching the UID is not as easy as it sounds because nowadays many vendors expect a certain UID or apply a new UID every time a new version of the application is installed. On OS/X i.e. it depends which username was created first.
The easiest solution seems to be the one where you squeeze all users into a common GID and change the umask to allow other group members to modify your content. In case you are not aware of it, every user can be member of multiple groups.
i.e. You create a group called SAN-USER with GID 900 you simply have to edit the /ect/groups file, add the new group and add the user to the new group. It has to be done on every Linux or MAC client of course.

SAN-USER:x:900:joe, doe, smoke2013

The default umask is 0022 which will result in a permission mask of 755. While this won’t allow other group members to modify files, you have to change the umask to 0002 (775 for files and 664 for directories).
We got Linux and OS/X to collaborate and now we tell Windows to do the same. There are variables for a filesystem which can be set to enforce UID, GID and permissions, just like Samba. Modify the configuration file and look for following lines:

UnixNobodyUidOnWindows                  60001
UnixNobodyGidOnWindows                  900
UnixFileCreationModeOnWindows           0664
UnixDirectoryCreationModeOnWindows      0775

A restart after of this modified filesystem will be required to make the changes affective.

This should give you a bit more control and less file touching again.