XSan is started during system startup by "launchd" along with every other service. Its up to the individual services launched at startup to handle their own prerequisites. The way XSan handles this is if an XSan client can't mount a volume, because not all disks are available, then as soon as the list of visible disks changes, XSan is notified and it tries again to mount any disks that are configured to mount which have not yet mounted.

* problem seen

To prevent failed mount attempts from occurring and generating log entries that suggest a problem that really isn't a problem since it resolves itself, with log entries in raslog or cvlog on the MDCs causing unnecessary concern or maybe even causing admins to be paged whenever a Mac reboots, you can delay Xsan startup by inserting a wrapper script that is launched by the "launchd plist" instead of xsand. There was an old example of how to do this for Snow Leopard clients in the article:

http://support.apple.com/kb/TS3556

This procedure can be adapted for a Lion or newer system. A very simple way is to have a script that sleeps a while, then starts XSan.

 

#!/bin/sh

# sleep 60 seconds before continuing

/bin/sleep 60

exec /System/Library/Filesystems/acfs.fs/Contents/bin/xsand $*

 

This would be used instead of the Ruby script in step 1 of TS3556. You would save this script somewhere on your system, make it executable, then modify the "launchd plist" to load this script instead of XSand, as per step 4 in TS3556.

 

            =================                 ====================                  =================                 ================

* problem seen

Under some circumstances, Xsan volumes configured to mount automatically at startup may not mount until a user has logged in.  Volumes mount correctly once a user logs in to the affected client. This cycle of mount/unmount can continue with the login window already established to the user's home path from the first mount, and the Xsan volume can't re-establish the mount because the path already exists.

Try running the command listed in the article below on all of the Xsan Client systems and see if the issue persists. Run this command as a Send Unix command in ARD as the root user:

	sudo defaults write /Library/Preferences/com.apple.loginwindow XAcctSearchInternalVolumes -bool false

 

http://support.apple.com/kb/TS4292

 

It prevents the system (specifically loginwindow) from unmounting local volumes which might be used as storage for external user homes. Even if you're not using external users, this might happen in rare situations--hence the article. Basically any local drive is off limits for unmounting.

 

            =================                 ====================                  =================                 ================

Disabling Sleep Mode on a MAC - http://support.apple.com/kb/HT1191

Use the following Terminal command (with an administrator password) to prevent the computer from sleeping:

sudo pmset -a disablesleep 1

When the value is set to 1, all sleep functions are disabled. The Sleep item in the Apple menu is also dimmed.

            =================                 ====================                  =================                 ================

 

 

* problem seen

End user sees a popup asking for the Admin password when they try to drag and drop folders or files to their Trash bin. However they are able to go into CLI and rm/rmdir -R them.

 

The root cause is due to the fact that we cannot move a folder from a StorNext Managed directory to an unmanaged one. This means that moving a file or folder to <MNT>/.Trashes, which is a folder, through Finder is not permitted.

 

We have described this behavior in bug under CR48194.

According to Apple there is a workaround for this.

Where the end user must disable the .Trashes folder.

 

The procedure is described in this Apple KB:49600

http://macosx.com/forums/mac-os-x-system-mac-software/49600-disable-trashes.html