Tags: Ubuntu
The Linux ecosystem includes filesystem support for disks from many operating sytems. Apples APFS is very nice with powerful features. Setting up APFS support on Linux/Ubuntu is tricky, however.
There are many reasons where a Linux user needs to mount a MacOS APFS drive. They may have a DMG file to read, or they may have a drive to share between a Mac and Linux. Generally speaking, why should our data be trapped in one kind of computer? Shouldn't we be able to use our data from any kind of computer? Hence, shouldn't every operating system be able to read/write file systems of any operating system?
That's overly idealistic. Here in the real world, each file system format is usually proprietary to the manufacturer of a given operating system. Drives created for one operating system are therefore usually usable only by computers running that operating system.
An exception is Linux, where the Linux community has developed file system drivers for most file system formats. Another exception is the nearly ubiquitous support for the FAT32 filesystem.
In my case, I regularly switch between Ubuntu and macOS laptops. The battery on my macOS laptop gave up the ghost, rendering the computer nonfunctional. That laptop has a 4 terabyte secondary drive holding the software development work I'm doing for a client. While waiting for the local computer repair shop to get a new battery, that work is trapped inside the non-functional computer. Therefore, the goal is to extricate the drive from that laptop, and install APFS support for Ubuntu to extract the files.
What is APFS - the Apple File System
APFS is the successor to Apple's HFS+ (a.k.a. Mac OS Extended). It is optimized for solid state drives, supports encryption, snapshots, data integrity, etc.
The feature most useful for me is its Volume support. With APFS the disk is partitioned using containers within which you can create volumes. To macOS, a volume appears as an independent partition on the disk. But, volumes are not like the partitions recognized by other operating systems. In old-school disk partitioning, one allocates so many Megabytes to each rigidly sized partition. A disk containing APFS volumes is partitioned in that way. An APFS partition contains an APFS container, which in turn contains the APFS volumes. APFS volumes do not have a fixed size, and share the space with other volumes within the same container.
I find it convenient to make one volume per area of work. For example, work related to my consulting client is in one volume, another for personal files, and so on.
APFS is proprietary to Apple. Therefore, APFS support for Linux is based on reverse engineering how APFS works. This, in turn, means that APFS support on Linux is incomplete, experimental, and that the people involved have done tremendous work to get this far.
The following is derived from a
superuser.com posting discussing the options.
Before going over the software options, let's take a look at the drive.
Exploring the APFS drive
The drive in my case is a regular 2.5" laptop drive, mounted in an external enclosure, connecting via a USB3 cable. There are of course many other scenarios. The bottom line is you must attach the APFS drive to your Ubuntu machine.
On Ubuntu the most obvious way to explore drives connected to the system is with the Disks GUI application.
This shows my drive. It has a small FAT32 partition, and a large APFS partition available as /dev/sdb2. Earlier I said my laptop has a 4 terabyte drive, and this one is 2 terabytes. I did not lie. Instead, a few months ago I noticed 4TB SSDs are available at extremely good prices, so I got one, replacing the 2TB drive that had been in my macOS laptop. The 2TB drive is currently in an external 2.5" case, and I used it to test reading APFS drives before committing to extracting the 4TB drive from my laptop.
It's a good idea to have the option to test APFS support in this way. It would be okay if the filesystem on this 2TB drive were damaged by errant software, because it is simply a spare drive lying in a drawer. It would be a major disaster if the 4TB drive in the laptop were damaged, however.
Another place to look is /var/log/kern.log where you'll find some messages printed as soon as the drive is connected.
The lsblk command shows the following:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
...
sdb 8:16 0 1.8T 0 disk
├─sdb1 8:17 0 200M 0 part
└─sdb2 8:18 0 1.8T 0 part
Another GUI application is GParted, which looks like so:
These are a few tools you may find useful for exploring your APFS drive.
Linux-APFS
Now that we can explore the APFS drive, let's turn back to the superuser.com posting. Two open source (free) tools were discussed, and a commercial tool.
Most promising in the long haul is
linux-apfs which has a regular file system driver, linux-apfs-rw. Currently it does not support encryption. It attempts to support read-write operation, but that's described as experimental. One of the answers in the superuser.com post includes a shell script to set up this driver from source code. I did so, but got this:
$ sudo mount -o vol=1 /dev/sdb2 /apfs/1
mount: /apfs/1: cannot mount; probably corrupted filesystem on /dev/sdb2.
Notice that this is the normal Linux mount command. The goal with linux-apfs-rw is integrating APFS support as a regular filesystem accessed with the normal mount command. The -o vol=1 option says to mount volume number 1. But, as you can see, the driver believes the drive is corrupted. Since MacOS was happy with this drive, it's highly unlikely to be corrupted, and instead it's likely there's a problem with the software.
The tools shown earlier only show the drive partitions. The APFS volumes are held within the APFS partition, and are invisible to these tools.
In any case, as promising as linux-apfs-rw is, we have to skip on to the other tool.
APFS FUSE
The FUSE suite are user-space filesystem drivers.
APFS FUSE is, as the name suggests, a FUSE driver for APFS (Apple File System).
The GitHub README supports software encrypted volumes and other features, but does not support a read-write mode. Instead, it only supports read-only mounting of APFS drives. In other words, this is a work in progress.
The superuser.com posting includes a shell script for compiling APFS FUSE from source, and its use. The build directory ends up containing several programs.
The first, apfsutil, lists the APFS volumes. It is run as so:
$ sudo ./apfsutil /dev/sdb2
[sudo] password for david:
Volume 0 6502FAEA-D13B-4569-9410-BAFABC8EBD3E
---------------------------------------------
Role: No specific role
Name: Extra (Case-insensitive)
Capacity Consumed: 488600719360 Bytes
FileVault: No
Snapshots:
...
This is very useful since the APFS volumes are otherwise invisible. It shows both the volume ID and volume name. That let me verify the volume number corresponding to the volume containing the files I'm interested in
The apfs-dump, well, the GitHub README talks about scanning a partition for clusters having correct checksums. That's surely useful for examining low-level details, but is not what we need to learn about.
The main entree in the APFS FUSE feast is apfs-fuse which handles mounting APFS file systems.
The usage is:
apfs-fuse <options> <device> <mount-directory>
The options are:
-d n: If n > 0, enable debug output.-f device: Specify secondary device for Fusion drive.-o opts: Comma-separated list of mount options.-l: Lax mode: when unexpected data is encountered, try to continue, even if this means returning potentially incorrect data.-v n: Instead of mounting the first volume in a container, mount volume n (starting at 0).-r recovery_key: Mount an encrypted volume by supplying a password or Personal Recovery Key (PRK).-s n: Find the container at offset n inside the device. This is useful when using an image file instead of a disk device, and therefore partitions are not exposed.-p n: Find the container at partition n inside the device.
This command can mount a device, like /dev/sdb2, or a DMG file.
As with the normal mount command, the final command-line argument is the directory on which the file system will appear.
In my case, I wanted to mount volume #4, which is done as so:
$ sudo ./apfs-fuse -v 4 /dev/sdb2 ~/mount/mac4
The -v 4 option says to use volume 4. The next option is the device containing the APFS volume, and the last is the mount-point in the file system.
There's no output. Let's inspect the mountpoint to see what happened:
$ ls ~/mount/mac4
ls: cannot access '/home/david/mount/mac4': Permission denied
$ sudo ls ~/mount/mac4
private-dir root
The mounted filesystem is owned by root and is not normally readable, hence you must use sudo. The root directory is where your files actually live.
A useful option is to run:
$ sudo nautilus ~/mount/mac4
This opens a GUI file browser window on the directory. As before, it must be run with sudo.
When you are done with the filesystem, it can be unmounted as so:
$ sudo umount ~/mount/mac4
That's the normal umount command for unmounting filesystems.
In my case, I used Nautilus to copy files from the volume to a directory on my laptop. Because it's run under sudo you should use sudo chown -R $USER ~/path/to/mountpt to change ownership of the files to yourself.
Commercial software for mounting APFS volumes on Linux
The superuser.com posting also references a commercial tool from
Paragon Software for mounting APFS volumes on Linux. It supports full read/write access to the volume, high performance, and so on.
The price is 40 euros. They sell products for both Linux and Windows on x86. For Linux on other CPUs, contact Paragon for pricing.
It appears to only support APFS drives, not DMG files.
It does not support HFS+ volumes, but Paragon has a separate product for that purpose.
It does not capable of formatting APFS volumes. And it cannot do anything with APFS volumes encrypted via a T2 Security chip.
Conclusion
That Linux is able to access so many file systems is a testament to the vibrant community around Linux. Most operating sytems do not have this flexibility.
Unfortunately, APFS filesystem support for Linux is not, at this time, able to fulfill the dream of reading and writing files on a disk removed from a Mac. Others may find it worthwhile to pay Paragon for the commercial package. For my purpose it was enough to retrieve the files, copying them to my Linux laptop, so that I could get back to work on my project while waiting for the repair shop to receive the replacement battery.
Bottom line, with a little bit of work one can retrieve files from a Mac and get back to work. Another win for Linux.
