How to use foreign file systems in macOS

Your Mac is able to read an audio CD, or most USB thumbs drive pre-formatted for a Windows. The Mac has supported foreign file systems for decades with a plug-in architecture that allows macOS to mount, read, and in some cases write to and from storage volumes formatted for other computers.

It also supports mounting of some remote network volumes on the desktop as if they were disks.

All of this is possible because of the Mac's foreign file system plugins. Each plugin sits between the native macOS file I/O programming interfaces (APIs), and the actual low-level device I/O code. When an I/O request is made to a storage volume, macOS first checks to see what format the volume is.

If it's a format macOS understands natively, it simply completes the I/O. But if the volume is formatted with a file system macOS doesn't natively understand, it looks for a foreign filesystem (FFS) plugin, and if it finds a match, reroutes the I/O request to the FFS plugin.

The plugin's code then takes over and handles the I/O request - marshalling data to or from the storage volume as requested.

Any number of file systems can be supported in macOS, as long as there is a matching plugin for each foreign volume format. In fact, macOS doesn't even have to know many details about foreign volume formats — each FFS plugin handles most of the work. macOS simply says "here, read the data at this location, and give it back to me," or "here, write this data and get back to me with a confirmation".

This plugin architecture allows FFS support to be easily expanded in the future to support more formats, and allows file systems to be updated independently of the operating system as a whole. Brilliant.

Built-in FFS Support

As of macOS 13 Ventura, macOS supports most Windows FAT formats, Windows NTFS volumes in read-only mode, ISO 9660 Compact Disc format, DVD (UDF), Blu-Ray, other ISO optical standards, and older Mac OS formats from decades ago such as HFS Plus used for MacOS Extended.

Plug-ins for macOS FFS live in 2 locations on the Startup Disk:

• /System/Library/Filesystems
• /Library/Filesystems

If you peek inside these 2 folders, you'll see code bundles, each with a ".fs" file extension. Dropping or installing a new valid .fs bundle in either of these locations, then logging out and back in again will give macOS access to all volumes which the new .fs bundle is designed to support.

In general, you don't want to mess with anything in /System/Library/Filesystems. That directory is used by the system and altering it might cause errors, crashes, or even corrupt data.

Any new FFS plugins you add should be added in /Library/Filesystems.

Networked File Systems

Also inside both folders is a subfolder named "NetFSPlugins". This folder contains .fs bundles which know how to connect to, mount, unmount, and read + write to a remote network server as if it was a networked volume on the desktop.

If you look inside /System/Library/Filesystems/NetFSPlugins, for example, you'll find .fs bundles for FTP, HTTP, Windows SMB shares, NFS, WebDAV, and others. Each of the networked .fs bundles knows how to communicate remotely with those network protocols to do I/O.

Each networked .fs bundle also mimics a real filesystem and "tricks" the Finder into thinking each remote resource is a storage device - so it can mount them as volumes on the Finder desktop. Once mounted, you can double-click them, drag files to and from the remote resource, drag files to the Trash, unmount them, and perform other Finder tasks seamlessly - all over a network.

Some FFS plugins may not support every Finder task beyond basic I/O - but many do. Some, for example, may not allow you to set Finder tags, or change permissions, or display complete info in Finder Get Info windows. Read-only .fs bundles will mount, read, and unmount FFS volumes, but you won't be able to write to them.

Since most .fs bundles work at the OS kernel level, they must be extremely well-written, tested, and reliable. One small bug in an .fs bundle can corrupt an entire volume and render it unmountable - and unrecoverable.

Apple has done a marvelous job making the FFS mechanism in macOS extremely robust, and few if any data corruption problems have been reported.

3rd Party FFS Bundles

The plugin system has opened opportunities for 3rd parties to write and release their own FFS solutions and several have done just that. Some are free, some you have to pay for. These include but are not limited to:

• Tuxera NTFS for Mac - a complete read+write NTFS FFS plugin for Windows NTFS volumes. $14 ntfsformac.tuxera.com.
• Paragon's NTFS for Mac.
• OpenAFS
• OpenZFS
• No-longer-supported ProFuse - support for Apple II ProDOS-format disks from the 1980's.

Most of these include an installer you can run to install .fs bundles to the right location automatically. Some don't include installers.

MacFUSE: Filesystems at the User-Level

In 2009 Amit Singh released MacFUSE - Mac File User Space Extension. The idea behind MacFUSE is that once installed, foreign filesystems can now be written in user space instead of in the kernel.

In theory, that makes them much easier to write and test since a bug in a MacFUSE file system won't bring the entire system to a halt the way an errant kernel-level FFS will.

Many macOS FFS MacFUSE plugins followed, including one for Google File System (GFS), Linux (ext) and others. MacFUSE hasn't been updated in over 10 years, but still appears to work for most FFS plugins in macOS 13 Ventura on Intel-based machines. Your mileage may vary.

One FUSE-based macOS FFS is TabFS from Omar Rizwan. Once installed, TabFS allows you to mount all your open browser tabs in a folder on your desktop and access them from there.

Once you know how foreign filesystems in macOS work, assuming you can find the correct one for the foreign volume format you want to mount and access, the rest becomes a seamless experience.