Apple Knowledge Base's picture

Xsan: Volumes may not mount at startup if no user logs in (Apple KB)

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.

Read more:

Apple Knowledge Base's picture

Xsan: Do not share a specific directory from multiple fileservers (Apple KB)

You should not share a specific directory from multiple fileservers.

Read more:

Apple Knowledge Base's picture

Auffinden der AppleCare-Registrierungsnummer (Apple KB)

Sie benötigen Ihre AppleCare-Registrierungsnummer, um einen kürzlich erworbenen AppleCare-Vertrag zu registrieren, falls dieser noch nicht registriert wurde.

Read more:

kolekole's picture

Storage space and affinities


we've got 75tb XSAN with one volume consisted of three storage pools. We've got three folders (i will name them here folderone, foldertwo and folderthree) where each folder has its own affinity. I will name pools storageone, storagetwo and storagethree here.

Storagethree has 21TB of space. Folderthree has affinity tied to this storage pool. Two days ago there was 4TB of space left on storagethree pool. After deleting more than half data from folderthree freed space in XSAN admin hasn't changed.

Ive seen threads here on this forum where people have experienced similar issues, but i wasn't able to figure whats going on still after reading them.

If free space on storagethree pool hits 0 will people be able to write to that folder?

How to fix this issue if this is an issue at all?

Thanks in advance!

Apple Knowledge Base's picture

Xsan, multimedia apps: Troubleshooting dropped frame issues (Apple KB)

Learn how to troubleshoot situations in which dropped frames occur when video is stored via Xsan media. "Dropped frames" refers to frames of video that are unintentionally skipped during capture, editing, or playout.

Read more:

wrstuden's picture

Notes on Xsan4

Notes on Xsan 4
As others have noted, Xsan 4's administration model is notably different from the model in all previous versions of Xsan. Here are some notes I have on the changes.

We have coined a new term, "Activation." "Upgrade" and "Migration" are two ways of taking the base operating system and configuration from a previous OS to Yosemite. "Promotion" is the act of updating to Server 4.0. We coined a corresponding term, "Activation," to describe taking an Xsan 3 or 2 configuration and moving it into Xsan 4. SAN Activation happens after Upgrade or Migration and also after Server Promotion. Activation happens first on the previous Xsan Primary MDC, and then happens on the other MDCs.

Xsan 4 no longer directly manages clients. We ran into too many issues where SAN operations would fail because one client was off-line. To address this, Xsan 4 uses ldap to store the SAN configuration. Now instead of having Xsan Admin update (push) the configuration on all machines, we have store a changed configuration in ldap and we inform all the clients that they need to re-parse (pull) the configuration.

We now run Open Directory on all the MDCs and they act as an OD cluster to replicate this information. Clients do not need to bind to these severs. If you previously had Xsan managing Users & Groups, Xsan will use that OD for its storage. If you have an external source for your Users and Groups, say AD, just use that for Users&Groups and don't worry about this OD cluster.

There are two direct consequences of this change.

First, Xsan 4 does not support Xsan 3 or earlier systems in the SAN. We do not lock them out of the fsm's, and you can perform a zero-down-time upgrade. The rub is that the older clients do not understand the messages we now send out when the configuration changes, nor do they understand the new message instructing clients to unmount a volume (as it is about to be stopped). In this respect they are akin to Linux or Windows clients in the SAN. If you want to stop a volume, these clients will not automatically unmount it. If you destroy a volume, these cients will not correctly forget it.

Second, we use Transport Level Security (TLS) in ldap when querying the configuration. As such, we need certificates to anchor the TSL trust. Certificates need DNS host names. So Xsan 4 requires DNS be configured on the Metadata Network. We expect many sites already had it, but we now will require it.

Unfortunately the error message you get today is unclear about this issue. So be forewarned.

A thrid issue is that all of the MDCs need to be in the same OD cloud. If you had a SAN before where Xsan was NOT managing users & groups but you had OD running on some of the MDCs, you need to ensure the Xsan 3 primary controller is in that OD cluster as the primary (ODM) before activating the SAN. Otherwise Xsan will see that OD is not running on the former primary, create it, and then you won't be able to activate MDCs which are in a different OD cloud; we require all SAN MDCs have the same OD master.

smashfacekeybrd's picture

Xsan 4


OS X 10.10 Yosemite includes Xsan 4. There are some ch-ch-changes.

xsanguy's picture

Xsan and OSX 10.9.5

Just upgraded some lab MDCs to 10.9.5. No problems to report, please chime in below with your experiences and recommendations.

Apple Knowledge Base's picture

Xsan: Client cannot access certain folders on Xsan volume, or cannot access an entire volume (Apple KB)

Learn how to resolve three scenarios that one may encounter when attempting to access files on Xsan volumes or the volumes themselves:

Scenario 1: A client may be unable to access folders on an Xsan volume. A red minus sign icon may appear on the folders, and when trying to access data, the Finder may state "The folder 'name' could not be opened because you do not have sufficient access privileges." If using the command line to attempt to navigate, this alert may appear: "Permission denied."

Scenario 2: A client may be unable to access a folder or Xsan volume, but no red prohibitory icon appears on the volume or folder icons. When trying to access the volume or a folder on it, the Finder may state "The folder 'name' could not be opened because you do not have sufficient access privileges." If using the command line to attempt to navigate, this alert may appear: "Permission denied."

Scenario 3: A client may not be able to perform basic file operations within an Xsan volume, or folder/file on the volume. In this situation, a lock icon may be visible on the volume/folder/icon in the Finder. This may occur even if the user's account has been given correct permissions. The Finder may become unresponsive.

Read more:

Apple Knowledge Base's picture

Xsan: Manually configuring Xsan after promoting OS X Lion to Lion Server (Apple KB)

Learn how to manually set up Xsan on Lion Server after promoting the system from the OS X Lion (client).

Read more:


Subscribe to Xsanity RSS