Xsan automount failures in macOS 14.2, 13.6.2/3, and 12.7.2

15 Dec 2023

Several Xsan administrators have been reporting problems on clients that have been upgraded to any of the latest point releases from Apple.  The clients fail to mount their Xsan volumes and even manually mounting with xsanctl mount VolumeName fails.  There has been much discussion and a work around found on MacAdmin Slack in the #Xsan channel, so join us over there.

The problem can be seen in mount-debug.n log files in /Library/Logs/Xsan/ (the n will be some number).  A working mount will show something like

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

mount_acfs: argc = 5
mount_acfs: argv[0] = </System/Library/Filesystems/acfs.fs/Contents/bin/mount_acfs>
mount_acfs: argv[1] = <-o>
mount_acfs: argv[2] = <nofollow>
mount_acfs: argv[3] = </dev/disk16>
mount_acfs: argv[4] = </Volumes/TestSan>
Tue Dec 12 07:38:39 PST 2023
find_IORegistryBSDName: searching for <disk16>
IOServiceMatching dictionary
{
IOProviderClass = IOMedia;
}
find_IORegistryContent: Content = Apple_Xsan
find_IORegistryContent: LabelName = TestSan


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

When the mount fails, you will see something like

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

mount_acfs: argc = 7
mount_acfs: argv[0] = </System/Library/Filesystems/acfs.fs/Contents/bin/mount_acfs>
mount_acfs: argv[1] = <-o>
mount_acfs: argv[2] = <owners>
mount_acfs: argv[3] = <-o>
mount_acfs: argv[4] = <nofollow>
mount_acfs: argv[5] = </dev/disk16>
mount_acfs: argv[6] = </Volumes/TestSan>
Thu Dec 14 08:14:23 PST 2023
find_IORegistryBSDName: searching for <disk16>
IOServiceMatching dictionary
{
IOProviderClass = IOMedia;
}
find_IORegistryContent: Content = Apple_Xsan
find_IORegistryContent: LabelName = TestSan
syntax error:
"rw,owners,nofollow"
^
Unrecognized option: 'owners'

Usage: mount_acfs [-t acfs] [-o options..] <filesystem> <local path>
Options:
...

Notice the Unrecognized option: 'owners' line.  Whatever was changed in the most recent point releases tries to add -o owners to the mount command, and that is not a valid option for mount_acfs.

The good news, is that AppleCare Enterprise Support has acknowledged the issue and indicates that Apple is working on a fix.

The group on Slack has also found a work around, but it will be need to be customized on each boot of the Mac.  First, note the /dev/disk# line in the failed log message.  Then as root we can create a mount point and run the mount_acfs command manually.

 % sudo mkdir /Volumes/TestSan

 % sudo /System/Library/Filesystems/acfs.fs/Contents/bin/mount_acfs -o nofollow /dev/disk16 /Volumes/TestSan

Filesystem TestSan mounted on /Volumes/TestSan

In the first line we create a directory for the volume to mount in, named the same as our Xsan volume name.  Then in the second line we run the mount_acfs command with the options from the mount-debug log.  Your options may be different depending on your volume configuration.  Just make sure not to include the -o owners option as that is the cause of the problem.  Also make sure to put your disk# in to the command.  This number could change on each boot of the Mac so I don’t think we can hard code it.

Here is a script that works on our test san that you can use as the basis for a script in your environment.  Again, the options needed for the mount may differ and this only works for a single Xsan volume. If anyone wants to make it more flexible, we are happy to update it.  sanMount_workaround

 

Share

Eric Hemmeter