Under certain circumstances, an Xsan volume may not mount after you restart an Xsan workstation. If you try to mount the volume with Xsan Admin, that may not work either.
This issue may occur when logging into an Xsan client computer with a user account whose home directory is located on an Xsan volume. If the login or automatic login occurs before the Xsan volume has mounted, the operating system will attempt to fulfill the automount instruction by locally creating a substitute home directory that has the same pathname as the intended mount:
/Volumes/<XsanVolumeName>/<PathToHomeDirectory>
where <XsanVolumeName> is a local directory (not the actual Xsan volume) that shares the same name as the Xsan volume. Because the OS created this folder with the same name as the Xsan volume, the actual Xsan volume won't be able to mount.
To avoid this situation, make sure that the Xsan client's IP address and hostname are resolvable via DNS (if you are running Xsan clients with dual interfaces on separate subnets, only the primary interface, which should be the public interface, needs to be resolvable via DNS). To verify this:
If the operating system created a new home directory due to this issue as described above, you'll need to delete the directory that bears the same name as the Xsan volume (do not delete the actual Xsan volume). First, be sure to examine the contents of the directory and back up any data that may have been saved there. Then use the following command in Terminal to delete the directory:
sudo rm -r /Volumes/<XsanVolumeName>
where <XsanVolumeName> is the name of the directory that was created. After you delete it, Xsan Admin should be able to mount the Xsan volume.