TL;DR

After installing OpenZFS on OS X:

Mac:~ user$ sudo zpool create <POOL> <DEVICE>
Mac:~ user$ sudo zfs create <POOL>/Users
Mac:~ user$ sudo zfs set com.apple.mimic_hfs=on <POOL>/Users
Mac:~ user$ sudo mv /Users /Users.bak
Mac:~ user$ sudo zfs set mountpoint=/Users <POOL>/Users
Mac:~ user$ sudo mv /Users.bak/* /Users/

Download and install ZFSLoadCheck, ensuring you issue sudo touch /Users/.zfsloadcheck.

Then presuming Linux has already been set up with ZFS on Linux:

user@Linux:~$ sudo zpool import -d <DEVICE> <POOL>
user@Linux:~$ sudo zpool cachefile=/etc/zfs/zpool.cache <POOL>

Now just set your Linux user to use the same UID:GUID as Mac OS and set /etc/passwd to point to /Users/<user>.

The Notion

The idea was to have three major partitions: Mac OS High Sierra, Arch Linux, and a shared partition that would store my user/home directory. The reason for this is that I primarily do cross-platform development and would like my two preferred operating systems to be available during travel.

The initial setup and install – which took some time due to learning how to setup rEFInd and much fury at the more modern Disk Utility.app’s insane pie chart partitioning system – used HFS+ for High Sierra, ext4 for Arch, and HFS+ for the shared partition.

From Linux’s perspective, the total partitions, with the important three noted, were:

Before and after each of the Tyger, Lyon, and Lyger partitions I also placed 128MB of free space as per Apple’s recommendations.

The Problem

After the initial install of both Arch Linux and Mac OS – along with rEFInd – I was met with a potential problem. HFS+ write access under Linux is experimental and must be enabled with the force option during mount. Although I was uncertain as to what potential issues could arise from forcing R/W HFS+ access, as it seemed to work during initial tests, I did not feel comfortable with keeping HFS+ as the shared partition in the event of file loss or corruption.

After an initial review of the potentially shared options of NTFS, HFS+ R/W or using ext4 via FUSE on Mac OS, I came to the conclusion that none of these were very good options. In the case of HFS+, it was uncertain what extended use would lead to, and in the case of ext4, the only reliable ext3/ext4 R/W “driver” came at a bit of a cost (not much, by any means). NTFS was denied on the principle of it – if I was triple booting, NTFS might have been the choice, although permission incompatibility would probably deny the shared user directory design.

With this, I then thought of another project I was working on…

The Solution

Having recently delved into ZFS – a filesystem I hadn’t touched since the late-aughts with Solaris – for a Debian office server, I realized that the answer to my problems could potentially be ZFS.

A quick search revealed that the OpenZFS on OS X project had matured much since my last viewing (as I had noticed of the ZFS on Linux project some weeks prior).

I began first by installing and setting it up on Arch Linux, following the guide here. Once this was complete, I simply issued the basic commands to setup a zpool:

sudo zpool create Lyon /dev/sda4

With this, the zpool Lyon was created, allowing me to copy over my home directory and begin using it by setting my entry in /etc/passwd to point to the appropriate Lyon zfs volume. I rebooted into Mac OS and issued the standard sudo zpool import and discovered that the Linux-made ZFS pool had setup an extended Linux-centric option that rendered it only able to mounted as read-only in Mac OS. This would not do, so I issued sudo zpool destroy Lyon and recreated it on Mac OS with sudo zpool create Lyon /dev/disk0s4. With this in place, I switched back to Linux and confirmed that it had R/W access to the same pool.

With the zpool working and visible between both, I decided to set up a generic Users volume within the Lyon zpool in the event of adding additional volumes or otherwise. This was merely a matter of issuing:

sudo zfs create Lyon/Users
sudo zfs set com.apple.mimic_hfs=on Lyon/Users

and thereafter moving the Mac OS partition’s Users contents to it and setting up the appropriate mount paths. As noted, I additionally enabled the com.apple.mimic_hfs setting in the event that I might run into problems with programs such as Photos (as indicated by the OpenZFS wiki).

On Mac OS, I backed up the root /Users directory, deleted the original, issued zfs set mountpoint=/Users Lyon/Users, then moved the original /Users/ contents into the mounted share.

On Linux, I logged in as root, simply used the same /Users/ mount point and set my /etc/passwd user entry to use /Users/kts, as I do not know if it is possible to have a ZFS volume have different mount locations based upon the current host. Additionally, I modified my user entry in /etc/passwd to use the same UID as used in Mac OS so there wouldn’t be mismatched ownership. I additionally added a new group that matched Mac OS’s staff GUID and made it my primary.

With all this in place – and omitting some some minor mistakes along the way – I safely rebooted back to Mac OS. However, upon attempting to login, it seemed the ZFS filesystem Lyon/Users was not mounted to /Users when I logged in. After some research into the matter, it appeared that mounting ZFS volumes takes some time to actually mount. After some initial tries with some basic LaunchDaemon scripts, I discovered ZFSLoadCheck, a rather simple LaunchAgent application that polls for a hidden dot file in the /Users location and lets you know if it finds that file or not. It does so by showing a small dialog on the Login screen that updates about every 5 seconds to let you know if it is yet time to login.

After putting ZFSLoadCheck’s files into place, I rebooted between Mac OS and Arch Linux multiple times and was able to log in perfectly each time – providing I waited a few moments for the ZFS volumes to actually mount.

And, with that, finally, shared ZFS on Mac OS & Linux was a success!