tl;dr
I wanted to store 100GB+ of LLM models on a portable USB drive to work across my Linux and Mac devices. My ext4-formatted drive worked perfectly on Linux but became a nightmare on macOS. Save yourself hours of frustration: use exFAT from the start if you need cross-platform compatibility.
The Problem: Too Many Models, Too Little Space
Working with local LLMs through ollama is fantastic, but the storage requirements are brutal. A single model family like deepseek-r1 spans from 1GB to over 400GB:
deepseek-r1:1.5b- 1.1GBdeepseek-r1:7b- 4.7GBdeepseek-r1:14b- 9.0GBdeepseek-r1:32b- 20GBdeepseek-r1:70b- 43GBdeepseek-r1:671b- 404GB
Add quantization variants and you're looking at hundreds of gigabytes for proper model evaluation. My Mac Mini's 256GB SSD can't handle this, and re-downloading models every time I want to test something wastes bandwidth and time.
My solution: A portable USB drive loaded with models that I can plug into any device. Download once, test everywhere. Simple, right?
Wrong. This is where I learned that cross-platform filesystem compatibility is still a mess in 2025.
Setting Up the USB Drive (And My First Mistake)
With my plan in place, I started downloading models using ollama-dl combined with a list of models in a text file and a bash script. The only requirement left was a fast internet connection.
I took the first USB device I found in the drawer of my desk, and quickly realized that I have some issues: The stick has 128GB, but is not really fast for writing, but this will be OK for my use case, as long as reading is fast. The other downside was that it used a FAT32 filesystem, and I got write errors after the first 4GB were written to the device.
Instead I used one of my other drives that I built with an NVMe SSD and a USB adapter. This device is way faster for transferring the models, and since I use it most of the time with my Linux devices I decided to use ext4 on the initial setup.
As this device worked perfectly for downloads, I adapted my script to save models directly onto the USB drive. Within a few hours, I had about 100GB of LLM models in .gguf format ready to go.
But here's where my filesystem choice came back to haunt me.
The macOS Reality Check
With my freshly loaded USB drive in hand, I confidently walked over to my Mac Mini, expecting a simple plug-and-play experience. Instead, I got... nothing. The drive wasn't even recognized.
Here's the root of the problem: ext4 is a Linux-native filesystem that macOS simply doesn't support out of the box. Apple has no incentive to add support for it, and the fundamental differences in how these operating systems handle file permissions and metadata make compatibility tricky.
After some googling, I found this tutorial from Jeff Geerling. It looked promising, but also surprisingly complex for what should be a basic operation.
In short you will need to run the following:
brew install pkg-config
brew install --cask macfuse
git clone https://github.com/gerard/ext4fuse.git && cd "$(basename "$_" .git)"
make
Plug in the USB device and run diskutil list in order to get the device id:
nezhar@Haralds-Mac-mini ~ % diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: Apple_APFS_ISC Container disk1 524.3 MB disk0s1
2: Apple_APFS Container disk3 245.1 GB disk0s2
3: Apple_APFS_Recovery Container disk2 5.4 GB disk0s3
/dev/disk3 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +245.1 GB disk3
Physical Store disk0s2
1: APFS Volume Macintosh HD 11.0 GB disk3s1
2: APFS Snapshot com.apple.os.update-... 11.0 GB disk3s1s1
3: APFS Volume Preboot 5.9 GB disk3s2
4: APFS Volume Recovery 969.1 MB disk3s3
5: APFS Volume Data 156.5 GB disk3s5
6: APFS Volume VM 20.5 KB disk3s6
/dev/disk4 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: *1.0 TB disk4
Create a directory to be used as our mount point:
mkdir ~/ext4_mount
Mount the device (make sure you are in the ext4fuse directory):
sudo ./ext4fuse /dev/disk4 ~/ext4_mount -o allow_other
The allow_other is important at this step, make sure not to misspell it like me with allow-other. Being late this took me a long time to figure out why the command was complaining of an invalid option.
After the mount command I discovered that I cannot continue from the System Extension Blocked message (I run macOS 15.1), as the Operating System has some security measures that need to be disabled. Some more details related to this issue can be found here.
For my Mac Mini this meant turning off the device, starting it and holding the power button in order to start inside the system recovery. Inside the system recovery there is a setting for the Startup Security Utility:
When opening this, you have to select the system and click the Security Policy button:
And now change the option to Reduced Security and Allow user management of kernel extensions from identified developers:
We can now retry to mount the device (make sure you are in the ext4fuse directory):
sudo ./ext4fuse /dev/disk4 ~/ext4_mount -o allow_other
This will need another restart, but now we can continue with the initial tutorial, and allow ext4fuse to be used on the system. For this you have to click on the Open System Preferences when the System Extension Blocked message is shown, and afterwards click allow for the extension.
Another restart is required, but from now on the mounting should work.
Even with allow_other option I still was not able to access the data, I required a console with root privileges.
Also make sure to use sudo umount ~/ext4_mount when you are done with your work.
Keep also in mind that this solution only allows reading from an ext4 device.
Verdict: It works, but barely. The complexity and security compromises made me wonder if there was a better way.
Solution No. 2: anylinuxfs
Frustrated with the macfuse approach, I kept searching and found a mention of anylinuxfs in a Reddit thread about this exact problem.
anylinuxfs has some advantages over macfuse:
- doesn't require installing any kernel extensions
- lowering system security is not required
- offers write support for mounted drives
The setup is easy and also faster:
brew tap nohajc/anylinuxfs
brew install anylinuxfs
You can afterward list the devices, you need root privileges to get more details:
nezhar@Haralds-Mac-mini ~ % anylinuxfs list
/dev/disk4 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: Unknown *1.0 TB disk4
nezhar@Haralds-Mac-mini ~ % sudo anylinuxfs list
/dev/disk4 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: ext4 Data *1.0 TB disk4
Mounting the drive is also easy:
sudo anylinuxfs /dev/disk4
This will start a container in the background and try to bind the volume using nfs. This takes a few seconds, and it mounted the drive, but sadly I was also only able to access it using root privileges.
Verdict: Better than macfuse in some ways, but still not the seamless experience I needed.
At this point, I had to ask myself: was I being stubborn by insisting on ext4?
Solution No. 3: Switching to exFAT (The Pragmatic Choice)
This issue shifted my focus a lot from my initial work, so I decided to take a pragmatic approach and switch to another file system that is compatible with macOS and is able to store large files. I'm not really a Mac user, so I asked around and after some research I found out that exFAT should suit my use case.
Formatting the stick as exFAT on Ubuntu requires also looking for advanced options during the formatting.
Meanwhile I acquired an additional 2TB USB Drive that I can freshly format:
You can now click on the cog icon in order to select the format option.
Make sure to select Other and click Next. Formatting the System as FAT will create a partition that is compatible across different systems, it will not work however with files larger than 4GB as the partition will be FAT32 formatted.
At this point the message that this is a system used for SDXC cards makes it a bit confusing, but exFAT is what we are looking for.
You will receive a warning, as all your data will be removed with the change of the partition. Just make sure you copy the data on your device or on another drive if you still need it.
After you are done you will be able to see the drive in the list with the partition details.
The moment of truth: I tested this freshly formatted drive on my Mac Mini, my Linux laptop, and even my Android phone. Everything worked immediately, no terminal commands, no security compromises, no root privileges needed.
Conclusion
After hours of wrestling with kernel extensions, security settings, and root privileges, the lesson is clear: sometimes the pragmatic choice beats the optimal one.
Here's what I learned:
- ext4 on macOS is technically possible but requires compromising system security and dealing with constant permission issues
- exFAT isn't perfect (slower performance, fewer features) but it works seamlessly across every platform I tested
- Cross-platform compatibility in 2025 still feels like we're solving problems from 2012
My recommendation: If you need portable storage that works across Linux, macOS, Windows, and mobile devices, skip the ext4 adventure and format with exFAT from day one. Your future self will thank you when you can focus on your actual work instead of fighting filesystems.
The real frustration isn't the technical limitations—it's that we shouldn't still be dealing with these compatibility issues in 2025. Until operating system vendors prioritize interoperability over their walled gardens, exFAT remains the path of least resistance for developers who just want their storage to work everywhere.