SAN permissions work around

Permissions on a SAN can become very complex.  The most flexible and widely adopted solution is a unified permissions (ex LDAP) solution.  LDAP requires an infrastructure and is outside the scope of this document but, depending on implementation, can offer user accountability and file traceability in addition to permission or access control.

One workaround is to manually synchronize the UIDs for all users of the SAN.  For example, set all user's UID to 501 across *nix (Mac, Linux, etc) and within StorNext configuration file for Windows clients.

First we need an understating of the current permissions.  By default the UID configured for use on DVS SAN equipment is 500.  Mac creates the first user as 501.  Windows does not have a *nix translatable UID by default and requires leveraging of services (StorNext, NFS, CIFS/SMB, etc.) to interpret a *nix UID.

The idea of manually synchronizing UIDs is simple, change the UID of all clients connecting to the SAN, or, change the UID that is used by a service allowing access to the SAN Volume.

• *nix (Mac/Linux) clients with block level (fiber channel) access have direct access to the file system and therefore need to change their local (client) UID to match what is used by the SAN.
• Windows clients with block level access will need a change made to the StorNext configuration file for each file system it connects to.
• All clients that connect via service (NFS, CIFS/SMB) will be utilizing the UID defined in the config file of that service.

 

When choosing a UID take into consideration the number of clients of each type, if you have more Mac clients than Windows/Linux then using a UID of 501 might be simpler to implement.  And conversely, if you are adding a few Mac systems to an established SAN using UID 500 then changing the UID of the Mac systems would seem more likely.

 

Assuming we will use UID 501 across a new SAN making full use of NFS, CIFS/SMB:

Change the StorNext file system configuration (ex. sncfgedit dvs-rt0) file updating:

<unixNobodyUidOnWindows>500</unixNobodyUidOnWindows>

to

<unixNobodyUidOnWindows>501</unixNobodyUidOnWindows>

and restart the file system or cvfs service (service cvfs restart)

 

Change the NFS configuration (ex. /etc/exports) file updating:

/media/spycer-vol0      *(rw,async,no_root_squash,all_squash,insecure,anonuid=500,anongid=500)

to 

/media/spycer-vol0      *(rw,async,no_root_squash,all_squash,insecure,anonuid=501,anongid=500)

and restart the NFS service (service nfs restart)

 

Change the CIFS/SMB configuration (/etc/samba/smb.conf) file updating:

guest account = dvssan

to a user with the correct UID

guest account = smbsan

and restart the Samba service (service smb restart)

or update the dvssan UID to 501

usermod -u 501 dvssan

*Note: this would then require all local filesystem files created/used by dvssan (UID 500) to be updated to UID 501

The permissions for all files within the volume would need to be sycronized.  As root run the following command:

chown -R 501:501 /path/to/SAN/mountPoint

Once complete, all new files within the SAN volumes will belong to the current user of whichever client you are connecting with.