# anylinuxfs mounts ext4 on a Mac by running Linux drivers in a microVM

> anylinuxfs gives a Mac full read-write access to ext4, btrfs, xfs, NTFS and ZFS volumes by spinning up a libkrun microVM that uses the real Linux filesystem drivers and exposing the result to the host over NFS, with no kernel extensions and without lowering the system security settings. The trade is that every mounted volume is a network drive to macOS, and the project is explicit about what that costs.

**nohajc/anylinuxfs** — macOS: mount any linux-supported filesystem read/write using NFS and a microVM

- Repository: https://github.com/nohajc/anylinuxfs
- Stars: 1,643 · Forks: 49
- Language: Rust
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/nohajc-anylinuxfs

## The problem with mounting a Linux filesystem on a Mac

Mounting third-party filesystems on macOS has always been tricky, and the project explains why with a short history. There is official support for reading NTFS, but otherwise the tools have been macFUSE based. For NTFS there is NTFS-3g, which the documentation calls a pretty mature driver, but for Linux filesystems there are only a couple of experimental solutions such as fuse-ext2 and ext4fuse. The reason is structural, since a driver that writes to an ext4 volume has to implement the same semantics the kernel does, including journaling, and a user space driver that gets one of those wrong corrupts data. The approach anylinuxfs takes is the one that avoids the problem rather than solving it. If you want a reliable solution with full write access, you need to run a Linux virtual machine with physical disk access and take care of exposing the mounted filesystem to the host, and this project does exactly that and streamlines it so that it is as easy as running one command in the terminal.

## A microVM, not a virtual machine

The implementation is the libkrun microVM hypervisor plus NFS, and the design constraint is stated in the one line under the logo, no kernel extensions and no lowering system security. That phrase is the whole argument for the project, because the alternative FUSE-based routes rely on kernel extensions, which cost system security. The libkrun route puts the filesystem driver inside a lightweight virtual machine that has direct access to the disk, and the host sees the result over NFS. The virtual machine is deliberately small. It is a stripped down version of Linux, there is not even a UEFI firmware, and the documentation says practically it takes only a couple of seconds before the drive is mounted and ready to use, which is not like a traditional virtual machine that takes a while to boot. The description of the mechanism is that the microVM spins up in the background, uses the real Linux drivers, and the mount appears as an NFS share on localhost, and that any mount options on the command line are forwarded to the Linux mount command.

## Installing it is three Homebrew commands

The tool is distributed as a Homebrew tap, and the install is three lines:

```bash
brew tap nohajc/anylinuxfs
brew trust nohajc/anylinuxfs
brew install anylinuxfs
```

The trust step exists because a custom tap is not trusted by default. This is a CLI utility, and the README points at a separate project, anylinuxfs-gui, for anyone who would rather have a graphical interface. The repository layout shows how much machinery is behind the command, with an anylinuxfs/ directory for the Rust code, a vmproxy/ directory and a vmrunner-sys/ directory for the hypervisor side, an init-rootfs/ directory and a freebsd-bootstrap/ directory for building the guest root filesystem, a .kernel-builder/ directory, a common-utils/ directory, an etc/ directory, a share/ directory, tests/, scripts/, docs/ and a .planning/ directory, along with a build-app.sh and a download-dependencies.sh script and an install.sh. The entitlements file anylinuxfs.entitlements at the root is a reminder that the macOS side needs permission to do disk and hypervisor things, and the presence of AGENTS.md, CLAUDE.md and GEMINI.md says the project expects machine agents to work on it.

## Six commands, and the disk identifier grammar

The command surface is small. anylinuxfs mount mounts a filesystem and is the default command, so the mount keyword can be omitted. anylinuxfs unmount does a safe unmount, which the documentation says is useful in case of multiple mounts, typically ZFS datasets, which need to be ejected in a particular order. anylinuxfs list shows available filesystems, with -m and -l showing Microsoft and Linux partitions only. anylinuxfs status shows what is currently mounted. anylinuxfs log shows details about the current or last run, which is the troubleshooting entry point. And anylinuxfs vm opens a shell or runs a command inside the virtual machine used for an active mount, which is the way to look at the real Linux environment when something is wrong. The mount command's usage block is worth reading because the disk identifier grammar is where the complexity lives:

```text
Usage: anylinuxfs [mount] [OPTIONS] [DISK_IDENT] [MOUNT_POINT]

Arguments:
  [DISK_IDENT]   File path(s), LVM identifier or RAID identifier, e.g.:
                 /dev/diskXsY[:/dev/diskYsZ:...]
                 path/to/disk.img@s1[:path/to/image.qcow2@s2:...]
                 lvm:<vg-name>:diskXsY[:diskYsZ:...]:<lv-name>
                 raid:diskXsY[:diskYsZ:...]
                 (see `list` command output for available volumes)
  [MOUNT_POINT]  Custom mount path to override the default under /Volumes
```

The rule that catches people out is that the identifier must always refer to one or more partitions or logical volumes, never a whole disk, and that a basic identifier is /dev/diskXsY, matching how anylinuxfs list or diskutil list identifies drives.

## The filesystem coverage is Linux's coverage

The feature list is where the project argues that using the real drivers is worth it. It mounts any filesystem supported by Linux, which means ext4, btrfs and xfs, but also NTFS and exFAT, with full read-write support because whatever Linux natively supports, anylinuxfs supports too. On top of that are the layers that a Mac user actually needs. LUKS-encrypted drives are supported. BitLocker-encrypted drives are supported, for NTFS or FAT32, using your recovery key as the passphrase. LVM is supported, including volume groups spanning multiple drives, and LVM on LUKS, so encrypted LVM. Linux RAID through mdadm and multi-disk btrfs are supported. ZFS is supported, including native ZFS encryption. Disks with GPT, MBR or no partition table at all work, a single filesystem or an LVM or LUKS container, as do disk images, currently raw and qcow2. And because the mount options are forwarded to the Linux mount command, you can pick btrfs subvolumes or mount read-only.

## The limitations are honest and specific

The limitations section is worth reading in full, because it is the cost of the approach. Only Apple silicon Macs are supported, and the reason given is a libkrun limitation, so an Intel Mac is out. A new virtual machine is needed for each mounted volume, with a configurable RAM limit of 512 MB by default and typical usage around 256 MB per VM. Multi-mount relies on file locks to prevent data corruption, and only whole physical partitions can be locked, so you can mount multiple logical volumes from the same partition only if you mount all of them read-only. By design, any mounted volume is seen by macOS as a network drive shared by the virtual machine, which is the same fact that produces the Word limitation, since Microsoft Word cannot edit files directly on a mounted drive, a known issue with Word and network filesystems. On the networking side, the NFS share is reachable from localhost only by default, but it can be shared across the network too, which is worth thinking about before you do it on a shared network.

## NTFS is the rough edge, and the documentation says so twice

The known issues section is where the project admits its own weak spot, and it is worth reading before you mount an NTFS drive. When copying a large number of files over an extended period, NTFS drives can throw I/O errors, and a retry usually fixes it. This only happens with the default ntfs-3g driver, which misbehaves in combination with NFS, which is the mechanism used to expose the files to macOS. The alternative is the ntfs3 driver, which does not have this issue, and the documentation explains why it is not the default, in a note referred to as the NTFS notes. There is a hope that the situation improves once yet another new NTFS driver lands in the Linux kernel. And there is a caution above the known issues, asking you to read the notes before using anylinuxfs with NTFS. The other known issue is that some disks with non-ASCII labels may fail to mount unless a custom mount point with safe characters is used, and that one is a macOS bug. The custom actions mechanism is the other extension point, letting you define your own actions, with a borg backup located on a Linux drive given as the example.

## Conclusion

anylinuxfs is the right tool if you need to work with a Linux filesystem on a Mac with confidence, because the alternative paths are experimental FUSE drivers, and this one uses the drivers Linux itself ships, which is why it supports the full set of filesystems and the full stack of encryption and volume management on top of them. It is the wrong tool on an Intel Mac, since it is Apple silicon only, and it is the wrong tool for an application that insists on local disk semantics, because every mounted volume is a network share and the project says so itself. Before you mount anything, read the NTFS notes, since the default driver is the least reliable one and the documentation asks for it explicitly, and plan for the per-volume virtual machine, since each mount spins one up and the guidance is a couple of seconds of startup per drive.

## FAQ

### How does anylinuxfs mount ext4 on macOS?

It spins up a libkrun microVM that has access to the physical disk and uses the real Linux filesystem drivers, then exposes the mounted filesystem to the host over NFS as a share on localhost. There are no kernel extensions involved and no lowering of the system security settings, and mount options given on the command line are forwarded to the Linux mount command.

### How do I install anylinuxfs?

With three Homebrew commands, brew tap nohajc/anylinuxfs, brew trust nohajc/anylinuxfs and brew install anylinuxfs. The project is a CLI utility, and a separate GUI project called anylinuxfs-gui is available if you prefer an interface.

### Which filesystems and encryption schemes does anylinuxfs support?

Anything Linux supports, including ext4, btrfs and xfs, as well as NTFS and exFAT, with full read-write access. It also supports LUKS-encrypted drives, BitLocker-encrypted NTFS and FAT32 using a recovery key as the passphrase, LVM including volume groups spanning drives, LVM on LUKS, Linux RAID through mdadm, multi-disk btrfs, and ZFS including native ZFS encryption, and it works with disk images in raw and qcow2 format.

### What are the limits of anylinuxfs on a Mac?

Only Apple silicon Macs are supported, a new virtual machine is needed for each mounted volume with a 512 MB default RAM limit, and multi-mount relies on file locks that work only at whole physical partition level, so multiple logical volumes from one partition need a read-only mount. Every mounted volume is a network drive, which is why Microsoft Word cannot edit files on it, and the default ntfs-3g driver can throw I/O errors over long copy operations, where the ntfs3 driver is the workaround.

## Sources

- [Issues](https://github.com/nohajc/anylinuxfs/issues)
- [License: GPL-3.0](https://github.com/nohajc/anylinuxfs/blob/main/LICENSE)
- [nohajc/anylinuxfs on GitHub](https://github.com/nohajc/anylinuxfs)
- [README](https://github.com/nohajc/anylinuxfs/blob/main/README.md)
- [Releases](https://github.com/nohajc/anylinuxfs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nohajc-anylinuxfs