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.
<unixNobodyUidOnWindows>500</unixNobodyUidOnWindows>
<unixNobodyUidOnWindows>501</unixNobodyUidOnWindows>
/media/spycer-vol0 *(rw,async,no_root_squash,all_squash,insecure,anonuid=500,anongid=500)
/media/spycer-vol0 *(rw,async,no_root_squash,all_squash,insecure,anonuid=501,anongid=500)
guest account = dvssan
guest account = smbsan
usermod -u 501 dvssan
chown -R 501:501 /path/to/SAN/mountPoint
0 Comments