Support in macOS for file systems has continued to change over the last couple of years. This article summarises support available for local file systems, in attached rather than network or cloud storage, in macOS 26.1 Tahoe.

APFS

This is the default file system for Macs and Apple’s devices, although macOS has standardised on its case-insensitive variant for general use, while iOS and other OSes use case-sensitive. The one common exception is with Time Machine backup storage, which requires case-sensitivity. The only situation in which HFS+ is still expected is for bootable macOS installers.

The most significant feature of HFS+ that is missing in APFS is directory hard links, a key feature of Time Machine backups made to HFS+ storage.

Multiple APFS volumes can share the same APFS partition (container), in contrast to other file systems supported by macOS, in which each partition is also a volume.

As universal as APFS is on modern Macs, it’s very rarely available on other computer systems, and the only support for other platforms is from Paragon for Windows or for Linux.

HFS+

The Macintosh Extended file system HFS+ is the predecessor to APFS and is still fully supported in macOS. It comes from an era of hard disks rather than SSDs and may still be preferred for use on hard disks. Early versions were prone to cumulative errors, particularly when crashes or kernel panics occurred. Those risks were mitigated with the introduction of journalling, and HFS+ should only be used with journalling enabled. Currently supported versions of macOS no longer support its HFS predecessor, though, as that was dropped in 2019.

The only remaining situation in which HFS+ is still required is for bootable macOS installers, as detailed here.

HFS+ lacks many of the modern features of APFS, including snapshots, sparse files, clone files, and firmlinks used to join System and Data volumes. Because support for encryption was implemented late, in Core Storage logical volume management, recent macOS doesn’t support encrypted HFS+. However, like APFS, HFS+ is capable of supporting Trim on SSDs. Each HFS+ volume is a partition, thus has fixed size, in contrast to APFS partitions (containers) which can contain multiple volumes.

ExFAT, FAT32

These are two of a family of file systems introduced for MS-DOS and Windows. Although the older FAT formats are now antiquated, ExFAT remains the most commonly encountered format for USB flash drives (thumb drives, memory sticks) and SD cards, where it’s the default format for SDXC and SDUC cards larger than 32 GB. Unlike FAT32, ExFAT supports massive volumes and file sizes, and was optimised for use in flash memory. However, its implementation in macOS doesn’t support Trim.

These formats have relatively basic features, and lack encryption. Used from a Mac, they don’t have support for document versions, and may encounter indexing problems with Spotlight. They do, though, support extended attributes by using AppleDouble file format, in which those are saved in shadow files with names starting with ._ (dot – underscore). While those shadow files preserve extended attributes for use with macOS, they can confuse Windows users, for whom they can be deleted, for example using Ross Tulloch’s BlueHarvest.

In recent versions of macOS, these file systems are implemented in user-space using FSKit.

NTFS

Although you won’t find any mention of it in Disk Utility, macOS includes read-only support for NTFS, enabling the one-way transfer of files from Windows. There are third-party products to extend that with write support, including an implementation from Paragon. NTFS is significant for its support of extended attributes as Alternate Data Streams (ADS).

Available formats

Disk Utility version 22.7 in macOS 26.1 Tahoe can format the following file systems using a GUID Partition Map:

• APFS, unencrypted case-insensitive
• APFS, encrypted case-insensitive
• APFS, unencrypted case-sensitive
• APFS, encrypted case-sensitive
• HFS+ journalled case-insensitive (JHFS+)
• HFS+ journalled case-sensitive
• ExFAT
• MS-DOS (FAT32).

The command tool diskutil additionally offers FAT, FAT12, FAT16, and HFS+ without journalling.

ZFS

The only other major file system that can be supported by Macs is ZFS, available as OpenZFS on OS X. That isn’t a trivial undertaking, and is dependent on a kernel extension.

Linux file systems

There doesn’t appear to be native support for Btrfs, which is best accessed through Linux virtualisation when needed. While you can use a VM for ext4 and its predecessors, Paragon also offers support for them that is claimed to be compatible with macOS Tahoe.

MacFUSE

Traditionally, native file systems are implemented in kernel-space, requiring a kernel extension for macOS. This remains the case for those used by the operating system and for performance-critical tasks. In other cases, it’s possible to implement a file system in user-space without the need for a kernel extension. This has been the goal of the FUSE project, and with the introduction of FSKit support for user-space file systems in macOS, the MacFUSE implementation now runs without any kext. It’s hoped that will open up access to more file systems in the future.

I’m very grateful to Robert for pointing out Paragon’s support for Linux Ext file systems.

Every self-respecting file system identifies files and directories using numbered data structures. In most modern file systems, those data structures are known as inodes, and their numbers are inode numbers, sometimes shortened to inodes. The term is thought to be a contraction of index node, which certainly makes sense, but is lost in the mists of time.

In any file system, for example an individual APFS volume, the inode numbers uniquely identify each inode, and each object within that file system has its own inode. Whatever else the file system might do, the inode number identifies one and only one object within it. Thus one invariant way of identifying any file is by referencing the file system containing it, and its inode number.

HFS+

The Mac’s original native file systems, ending most recently in Mac OS Extended File System, or HFS+ from its origins in the Hierarchical File System, don’t use inodes as such, and don’t strictly speaking have inode numbers. Instead, the data structures for their files and folders are kept in Catalogue Nodes, and their numbers are Catalogue Node IDs, CNIDs.

With Mac OS X came Unix APIs, and their requirement to use inodes and inode numbers. As CNIDs are unique to each file and folder within an HFS+ volume, for HFS+ they are used as inode numbers, although in some ways they differ. CNIDs are unsigned 32-bit integers, with the numbers 0-15 reserved for system use. For example, CNID 7 is normally used as the Startup file’s ID.

Although not necessarily related to CNIDs, it’s worth noting that the Mac’s original file system MFS allowed a maximum of 4,094 files, its successor HFS was limited to 65,535, and HFS+ to 4,294,967,295. Those are in effect the maximum number of inode numbers or their equivalents allowed in that file system.

APFS

Unlike HFS+, APFS was designed from the outset to support standard Posix features, so has inodes numbered using unsigned 64-bit integers.

Strictly, the APFS inode number is the object identifier in the header of the file-system key. Not all unsigned 64-bit integers can be used as inode numbers, though, as a bit mask is used, and the number includes an encoded object type. APFS also makes special allowance for volume groups consisting of firmlinked System and Data volumes, to allow for their inode numbers to remain unique across both volumes. Officially, those allow for a maximum number of inode numbers of 9,223,372,036,854,775,808, either in single APFS file systems, or shared across two in a volume group.

Every file in APFS is required to have, at an absolute minimum, an inode and its associated attributes, shown above in blue, including a set of timestamps, permissions, and other essential information about that file.

There are also three optional types of component:

• although some files may be dataless, most have data, for which they need file extents (green), records linking to the storage blocks containing that file’s data (pink);
• smaller extended attributes (yellow), named metadata objects that are stored in a single record;
• larger extended attributes (yellow), over 3,804 bytes in size, whose data is stored separately in a data stream.

Interpretation

When looking at inode numbers in volume groups, they can be used to determine which of the firmlinked file systems contains any given file. Both volumes share the same volume ID, and files in the System volume have very high inode numbers, while those in the Data volume are relatively low. I have given further details here.

Inode numbers are more generally useful in distinguishing files whose data appears identical, and the behaviour of various methods of linking files.

Copying a file within the same file system (volume) creates a new file with its own inode number, of course. However, duplicating a file within the same file system results in an APFS clone file, with a distinct inode, although it shares common data, so their inode numbers are also different.

Instead of duplicating everything, only the inode and its attributes (blue and pink) are duplicated, together with their file extent information. There’s a flag in each clone file’s attributes to indicate that cloning has taken place.

A symbolic link or symlink is merely a pointer to the linked file’s path, and doesn’t involve inode numbers at all. Because of that, changing the linked file’s name or path breaks its link. Finder aliases and their kindred bookmarks do contain inode numbers, so should be able to cope with changes to the linked file’s name or path, provided it remains in the same file system and doesn’t change inode number.

Hard links are more complex, and depend on the way in which the file system implements them, although the fundamental rule is that each object that’s hardlinked to the same file has the same inode number. According to Apple’s reference to APFS, this is how it handles hard links.

When you create a hard link to a file (blue), APFS creates two siblings (purple) with their own IDs and links, including different paths and names as appropriate. Those don’t replace the original inode, and there remains a single file object for the whole of that hardlinked file.

Inode attributes keep a count of the number of links they have to siblings in their link (or reference) count. Normally, when a file has no hard links that’s one, and there are no sibling files. When a file is to be deleted, if its link count is only 1, the file and all its associated components can be removed, subject to the requirements of any clones and applicable snapshots. If the link count is greater than 1, then only the sibling being removed is deleted.

Easy access

Inode numbers are readily accessed using command tools in Terminal. For example, ls -i lists items with their inode numbers shown. One free utility that displays full information about inode numbers and much more is Precize.

The volume ID is given as the first number in the volfs path, and the second is the inode number of that file within that. Note that the File Reference URL (FileRefURL) uses a different numbering system, and the Ref count of 1 indicates this file has no hard links.