Tag Archives: Xsan

Stornext and Active Directory ACL Permissions

If you run a heterogeneous shared storage environment (such as a stornext system), you may find this information about ACLs useful.

*NIX systems use POSIX 1e standard ACLs. Windows, Mac, and [some] others use NFSv4 standard ACLs. In a Stornext SAN environment, MacOS and Windows are not able to use the POSIX 1e ACLs that the Linux host writes on the files and directories. Likewise, Linux is unable to see the NFSv4 ACLs that a Windows machine or a Mac writes. This can create some major problems if ACLs are essential to your workflow.

Linux writes POSIX.1e ACLs.
Win & Mac write NFSv4 ACLs.
These two standards are NOT compatible.

Filesystem ACLs


So what is the solution? Well to be perfectly frank, there isn’t any easy solution. I’ve used several options with varying degrees of success based on the situation:

  1. Periodic Permission Repair Script – A not-very-elegant, but still working solution is to run a script from a Mac SAN client. The script should execute periodically (via launchd) to set permissions in a given folder to whatever your desired setup is. Running this from a mac allows you to set the POSIX bits (for Linux access) and the ACLs (for Mac/Win access). Once you set this properly via chmod, the permissions should work as intended. What this means is that you’ll need to have an “cleaning” folder that you drop items into, allow the script to run, then remove them.
    GOTCHAS: You’ll want this to run frequently so your users don’t have to wait too long, but if you have a large volume, it could respawn while its previous instance is still running. If left unresolved this could cause a
  2. Triggered Permission Repair Script – Similar to the option above, but provide a file path to the script, and a user (assuming they have admin access) can execute said script. If you dont want to dole out administrative access to machines, but still want to be able to trigger a repair, consider a web-interface on said Mac client with a PHP command to trigger a local bash script.
  3. Perimeter Protection – Hard on the outside, soft and chewy in the center. Consider setting a top-level directory to have very restrictive POSIX and ACL permissions, but have everything underneath opened up. You’d need to set your umask on all machines to 000 (along with the windows equivalent), but it will eliminate most permissions problems down the road.
    GOTCHAS: not gonna work if you need to have various levels of permission on variously nested directories.




(Currently on Linux there is  a compatibility for systems running ZFS with NFSv4 ACLs (and this is beta). Other filesystems (i.e. CVFS) have no samba compatibility with the NFSv4 ACLs)

Adding Xsan Clients to a Stornext Environment

Charles Edge has a great how-to for adding an Xsan client to a Stornext SAN here:
http://krypted.com/xsan/adding-xsan-clients-to-stornext-environments/ (link broken)
This will get you setup if you have no clients on the SAN, and frankly its probably the “right” way to do it. But there is a quicker way if you already have some Xsan clients attached and you just want to add more. (more…)

Xsan Maintenance

The proper Xsan volume maintenance is critical to the health of your filesystem. Short of a full crash with loss of configuration files, I have not seen any minor problems that this didn’t take care of (or at least help out tremendously). I try to do this to each volume at least once a month, and anytime there is a problem (i.e. filesystem crash). Start by stopping the volume: (more…)

Identify a file by inode

If you need to know what file a particular inode is associated with, you can use the following command:

find /Volumes/[volumename] -inum [number]

This can be useful in when used with the cvadmin command: “repof” to get a report of open files. You may need to do this if you find that a particular command will not execute due to open files.