Expedite progress – think in the future, become estranged from the now.
Mac OS High Sierra and Arch Linux with Shared ZFS Homes
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 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:
|1||EFI||EFI boot partition||FAT||200 MB|
|2||Tyger||High Sierra system partition||HFS+||36.6 GB|
|3||Recovery HD||High Sierra recovery partition||Apple boot||619.9 MB|
|4||Lyon||Shared partition||?||55.9 GB|
|5||Lyger||Arch Linux system partition||ext4||18.3 GB|
Before and after each of the Tyger, Lyon, and Lyger partitions I also placed 128MB of free space as per Apple’s recommendations.
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…
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.
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!