When you’re dealing with file ownership and permissions, context is very important. Xsan volumes, from the point of view of an Xsan client, are local storage. There’s no daemon acting as gatekeeper or mediator, so when files are created or modified, the clients will use the standard mechanisms for assigning ownership and access rights, as they would with any local drive. In the absence of a shared authentication context, local user accounts will end up owning the files, and their permissions will be according to the default umask.
Mac OS X keeps track of such things by numerical User ID, and all Mac OS X systems start assigning local UIDs beginning with 501. It shouldn’be be too difficult to see how this can end badly. Users will potentially be able to overwrite files owned by other users, or access files they shouldn’t be able to, or not be able to access files that they should.
A directory service, therefore, is a key component in a proper deployment of Xsan. A directory service provides a shared context that will keep User ID collisions from happening. Also, users and groups can be managed centrally, and not on each workstation. This is especially important in large Xsan environments. Also, it will be possible to leverage Access Control Lists, and not POSIX permissions, to manage access to files and folders. POSIX permissions aren’t flexible enough to effectively manage the requirements of most Xsan environments.
It doesn’t matter whether you’re using Open Directory, Active Directory, or a Golden Triangle. You can even integrate Xsan with Novell’s eDirectory. Any of these will provide a much smoother and easy to manage Xsan.