I’m posting this because this problem was incredibly difficult to diagnose, and someone with the same symptoms could easily conclude that their drive or data is corrupted when it may not be.
THE PROBLEM
I have a 24 TB exFAT drive containing a very large media collection. The data was copied to the drive using Windows.
Windows could see everything on the drive normally. I could browse the directories and play the files.
On my M1 Mac, however, the exact same drive behaved bizarrely.
macOS mounted the drive successfully. It could see a huge amount of the data — including roughly 18 TB of movies — but some folders were completely empty, while others contained only some of the files/directories that Windows could see.
For example, the Music folder appeared in Finder, but its contents did not.
Terminal showed essentially an empty directory:
ls -la "/Volumes/24TB - B/Music"
Yet Windows showed the Music directory normally.
Even stranger, some directories produced:
Invalid argument
For example:
ls -la "/Volumes/24TB - B/MAC TEST/A-Ha"
returned:
ls: /Volumes/24TB - B/MAC TEST/A-Ha: Invalid argument
That particular test folder was important because it was a NEW directory created on Windows specifically for testing. Windows could read it perfectly.
WHAT DID NOT FIX IT
Disk Utility First Aid reported the exFAT filesystem was fine:
Performing fsck_exfat
...
The volume 24TB - B appears to be OK.
File system check exit code is 0.
Operation successful.
I also upgraded macOS to the newest version available to me.
No change whatsoever.
Windows still saw the missing files. macOS still didn't.
At that point, I wanted to determine whether the problem was actually Apple's exFAT implementation rather than the disk.
THE TEST THAT FINALLY SOLVED IT
I installed macFUSE using Homebrew:
brew install --cask macfuse
On Apple Silicon, macFUSE requires third-party kernel extensions to be permitted.
In Recovery Mode, my Mac was configured for:
Reduced Security
and:
Allow user management of kernel extensions from identified developers
If you need to change this, shut down an Apple Silicon Mac, hold the power button until Startup Options appears, enter Recovery, and open:
Utilities → Startup Security Utility → Security Policy
NOTE: This changes an important macOS security setting. Understand what it does before enabling it.
After macFUSE was installed and approved, I loaded it with:
sudo /usr/bin/kmutil load -p /Library/Filesystems/macfuse.fs/Contents/Extensions/26/macfuse.kext
NOTE: The "26" path above corresponded to my macOS installation/macFUSE version. Verify the actual Extensions directory on your system rather than blindly copying that path.
I verified macFUSE was loaded with:
kmutil showloaded | grep -i fuse
Mine showed:
io.macfuse.filesystems.macfuse.25 (5.3.3)
So macFUSE was active.
BUILDING AN INDEPENDENT EXFAT DRIVER
Homebrew did not provide exfat-fuse when I tried:
brew search exfat
So I built the open-source exfat/exfat-fuse implementation from source.
The version I used identified itself as:
FUSE exfat 1.4.0 (libfuse3)
After configuring/building it, the mount executable on my machine was:
~/exfat/fuse/mount.exfat-fuse
Running:
make
confirmed the project was built.
IDENTIFY THE PROBLEMATIC EXFAT PARTITION
I ran:
diskutil list
My 24 TB drive appeared as:
/dev/disk7 (external, physical):
0: GUID_partition_scheme *24.0 TB disk7
1: Microsoft Basic Data 24TB - B 24.0 TB disk7s1
So MY exFAT partition was:
/dev/disk7s1
IMPORTANT:
DO NOT blindly copy /dev/disk7s1.
Device identifiers can change between Macs, drives, connections and reboots.
Run diskutil list and identify YOUR drive.
UNMOUNT APPLE'S EXFAT DRIVER
I released the partition from Apple's native filesystem driver without physically disconnecting the drive:
diskutil unmount /dev/disk7s1
It returned:
Volume 24TB - B on disk7s1 unmounted
CREATE A FUSE MOUNT POINT
I created a separate mount point:
sudo mkdir -p "/Volumes/24TB-B-FUSE"
Then I mounted the SAME exFAT partition using exfat-fuse instead of Apple's native exFAT implementation.
For safety, I mounted it READ-ONLY:
sudo "$HOME/exfat/fuse/mount.exfat-fuse" -o ro /dev/disk7s1 "/Volumes/24TB-B-FUSE"
It returned:
FUSE exfat 1.4.0 (libfuse3)
I verified the mount with:
mount | grep "24TB-B-FUSE"
which showed:
/dev/disk7s1 on /Volumes/24TB-B-FUSE (macfuse, read-only, synchronous)
AND SUDDENLY THE "BROKEN" DIRECTORIES WORKED
This was the decisive test.
Remember the Windows-created test directory where Apple's native exFAT implementation returned:
Invalid argument
I tried the exact same directory through FUSE:
ls -la "/Volumes/24TB-B-FUSE/MAC TEST/A-Ha"
It immediately worked.
The actual directories appeared:
Aha - 1985 - Hunting High and Low (1985)
Aha - 1986 - Scoundrel Days (1986)
Aha - 1988 - Stay on These Roads (1988)
Aha - 1990 - East of the Sun, West of the Moon (1990)
Aha - 1993 - Memorial Beach (1993)
Same Mac.
Same physical drive.
Same exFAT partition.
Same on-disk directory.
Apple native exFAT driver:
Invalid argument
exfat-fuse:
Directory opens normally.
THE MISSING MUSIC LIBRARY REAPPEARED TOO
Under Apple's driver, Music had appeared essentially empty.
Through FUSE:
ls -la "/Volumes/24TB-B-FUSE/Music"
The directories appeared.
I then counted the immediate children:
find "/Volumes/24TB-B-FUSE/Music" -mindepth 1 -maxdepth 1 -print | wc -l
Result:
404
That was particularly significant because 404 was exactly the expected count based on what Windows saw.
So exfat-fuse wasn't merely finding "some more stuff."
It was reproducing the directory contents Windows could see while Apple's native exFAT implementation could not.
FINDER COULD SEE THE MISSING DIRECTORIES TOO
Once mounted through FUSE, Finder displayed the previously problematic root directories.
Folders such as Music, Podcast, Demos - Logic, Emulation, GPT Convo, Guitar tones, Text and others that had been missing, empty or inaccessible through Apple's native exFAT implementation were now visible.
A very large Movies directory eventually populated with its complete set of subdirectories.
Most importantly, I opened an actual approximately 1 GB movie directly from the FUSE-mounted 24 TB drive.
It played normally.
So this wasn't merely directory recovery.
The actual file data could be read.
PERFORMANCE
There is an important caveat.
Finder can be noticeably slower browsing enormous directories through FUSE.
However, Finder does much more than simply request filenames. It performs metadata lookups, previews, icons, extended-attribute operations and other work.
I therefore tested raw directory enumeration separately.
For the Music directory:
time ls -1 "/Volumes/24TB-B-FUSE/Music" >/dev/null
The entire 404-entry directory enumerated in:
2.728 seconds
So raw filesystem access was considerably more reasonable than Finder made it appear.
Actual movie playback also worked normally in my initial testing.
I am now testing this configuration as storage for a Jellyfin media server.
WHY I USED READ-ONLY MODE
Notice the:
-o ro
in my mount command.
That means exfat-fuse was NOT allowed to modify the 24 TB filesystem.
This made the experiment particularly useful.
Nothing was repaired.
Nothing was reformatted.
Nothing was recopied.
Nothing on the filesystem was rewritten.
The sequence was simply:
For an archival media drive, read-only may also be desirable long-term. A media server such as Jellyfin can read the media while keeping its database, cache, thumbnails, metadata and transcoding files elsewhere.
WHAT THIS DEMONSTRATED
In my case, the evidence strongly indicates an interoperability/implementation problem with Apple's native exFAT handling rather than missing files or a failed copy.
The comparison was:
WINDOWS EXFAT IMPLEMENTATION
↓
Sees directories and files
APPLE NATIVE EXFAT IMPLEMENTATION
↓
Same filesystem
Missing/incomplete directories
"Invalid argument"
EXFAT-FUSE ON THE SAME MAC
↓
Same filesystem
Complete directories
Correct file counts
Files open and play
Nothing on the disk changed between the Apple-driver and FUSE-driver tests.
IF YOU ARE EXPERIENCING THIS
If you found this post because you have an exFAT disk where:
- Windows sees files/directories that macOS doesn't
- Finder shows folders as empty
- macOS sees only some entries in a large directory
- Terminal gives "Invalid argument"
- Disk Utility / fsck_exfat says the filesystem is OK
- The supposedly missing files still work normally in Windows
DO NOT IMMEDIATELY ASSUME YOUR DATA IS GONE.
And especially do not immediately reformat the disk simply because macOS can't see everything.
Try the disk under Windows first.
If Windows sees the supposedly missing data, consider testing the volume READ-ONLY using an independent exFAT implementation.
In my case, macFUSE + exfat-fuse 1.4.0 immediately exposed directories Apple's native exFAT implementation could not read.
I spent an absurd amount of time troubleshooting the disk, migration, filenames, filesystem integrity, macOS version and everything else because macOS successfully mounted the volume and showed MOST of it.
That partial failure was incredibly misleading.
The files weren't missing.
macOS's native exFAT implementation simply wasn't showing them.
THE PROBLEM
I have a 24 TB exFAT drive containing a very large media collection. The data was copied to the drive using Windows.
Windows could see everything on the drive normally. I could browse the directories and play the files.
On my M1 Mac, however, the exact same drive behaved bizarrely.
macOS mounted the drive successfully. It could see a huge amount of the data — including roughly 18 TB of movies — but some folders were completely empty, while others contained only some of the files/directories that Windows could see.
For example, the Music folder appeared in Finder, but its contents did not.
Terminal showed essentially an empty directory:
ls -la "/Volumes/24TB - B/Music"
Yet Windows showed the Music directory normally.
Even stranger, some directories produced:
Invalid argument
For example:
ls -la "/Volumes/24TB - B/MAC TEST/A-Ha"
returned:
ls: /Volumes/24TB - B/MAC TEST/A-Ha: Invalid argument
That particular test folder was important because it was a NEW directory created on Windows specifically for testing. Windows could read it perfectly.
WHAT DID NOT FIX IT
Disk Utility First Aid reported the exFAT filesystem was fine:
Performing fsck_exfat
...
The volume 24TB - B appears to be OK.
File system check exit code is 0.
Operation successful.
I also upgraded macOS to the newest version available to me.
No change whatsoever.
Windows still saw the missing files. macOS still didn't.
At that point, I wanted to determine whether the problem was actually Apple's exFAT implementation rather than the disk.
THE TEST THAT FINALLY SOLVED IT
I installed macFUSE using Homebrew:
brew install --cask macfuse
On Apple Silicon, macFUSE requires third-party kernel extensions to be permitted.
In Recovery Mode, my Mac was configured for:
Reduced Security
and:
Allow user management of kernel extensions from identified developers
If you need to change this, shut down an Apple Silicon Mac, hold the power button until Startup Options appears, enter Recovery, and open:
Utilities → Startup Security Utility → Security Policy
NOTE: This changes an important macOS security setting. Understand what it does before enabling it.
After macFUSE was installed and approved, I loaded it with:
sudo /usr/bin/kmutil load -p /Library/Filesystems/macfuse.fs/Contents/Extensions/26/macfuse.kext
NOTE: The "26" path above corresponded to my macOS installation/macFUSE version. Verify the actual Extensions directory on your system rather than blindly copying that path.
I verified macFUSE was loaded with:
kmutil showloaded | grep -i fuse
Mine showed:
io.macfuse.filesystems.macfuse.25 (5.3.3)
So macFUSE was active.
BUILDING AN INDEPENDENT EXFAT DRIVER
Homebrew did not provide exfat-fuse when I tried:
brew search exfat
So I built the open-source exfat/exfat-fuse implementation from source.
The version I used identified itself as:
FUSE exfat 1.4.0 (libfuse3)
After configuring/building it, the mount executable on my machine was:
~/exfat/fuse/mount.exfat-fuse
Running:
make
confirmed the project was built.
IDENTIFY THE PROBLEMATIC EXFAT PARTITION
I ran:
diskutil list
My 24 TB drive appeared as:
/dev/disk7 (external, physical):
0: GUID_partition_scheme *24.0 TB disk7
1: Microsoft Basic Data 24TB - B 24.0 TB disk7s1
So MY exFAT partition was:
/dev/disk7s1
IMPORTANT:
DO NOT blindly copy /dev/disk7s1.
Device identifiers can change between Macs, drives, connections and reboots.
Run diskutil list and identify YOUR drive.
UNMOUNT APPLE'S EXFAT DRIVER
I released the partition from Apple's native filesystem driver without physically disconnecting the drive:
diskutil unmount /dev/disk7s1
It returned:
Volume 24TB - B on disk7s1 unmounted
CREATE A FUSE MOUNT POINT
I created a separate mount point:
sudo mkdir -p "/Volumes/24TB-B-FUSE"
Then I mounted the SAME exFAT partition using exfat-fuse instead of Apple's native exFAT implementation.
For safety, I mounted it READ-ONLY:
sudo "$HOME/exfat/fuse/mount.exfat-fuse" -o ro /dev/disk7s1 "/Volumes/24TB-B-FUSE"
It returned:
FUSE exfat 1.4.0 (libfuse3)
I verified the mount with:
mount | grep "24TB-B-FUSE"
which showed:
/dev/disk7s1 on /Volumes/24TB-B-FUSE (macfuse, read-only, synchronous)
AND SUDDENLY THE "BROKEN" DIRECTORIES WORKED
This was the decisive test.
Remember the Windows-created test directory where Apple's native exFAT implementation returned:
Invalid argument
I tried the exact same directory through FUSE:
ls -la "/Volumes/24TB-B-FUSE/MAC TEST/A-Ha"
It immediately worked.
The actual directories appeared:
Aha - 1985 - Hunting High and Low (1985)
Aha - 1986 - Scoundrel Days (1986)
Aha - 1988 - Stay on These Roads (1988)
Aha - 1990 - East of the Sun, West of the Moon (1990)
Aha - 1993 - Memorial Beach (1993)
Same Mac.
Same physical drive.
Same exFAT partition.
Same on-disk directory.
Apple native exFAT driver:
Invalid argument
exfat-fuse:
Directory opens normally.
THE MISSING MUSIC LIBRARY REAPPEARED TOO
Under Apple's driver, Music had appeared essentially empty.
Through FUSE:
ls -la "/Volumes/24TB-B-FUSE/Music"
The directories appeared.
I then counted the immediate children:
find "/Volumes/24TB-B-FUSE/Music" -mindepth 1 -maxdepth 1 -print | wc -l
Result:
404
That was particularly significant because 404 was exactly the expected count based on what Windows saw.
So exfat-fuse wasn't merely finding "some more stuff."
It was reproducing the directory contents Windows could see while Apple's native exFAT implementation could not.
FINDER COULD SEE THE MISSING DIRECTORIES TOO
Once mounted through FUSE, Finder displayed the previously problematic root directories.
Folders such as Music, Podcast, Demos - Logic, Emulation, GPT Convo, Guitar tones, Text and others that had been missing, empty or inaccessible through Apple's native exFAT implementation were now visible.
A very large Movies directory eventually populated with its complete set of subdirectories.
Most importantly, I opened an actual approximately 1 GB movie directly from the FUSE-mounted 24 TB drive.
It played normally.
So this wasn't merely directory recovery.
The actual file data could be read.
PERFORMANCE
There is an important caveat.
Finder can be noticeably slower browsing enormous directories through FUSE.
However, Finder does much more than simply request filenames. It performs metadata lookups, previews, icons, extended-attribute operations and other work.
I therefore tested raw directory enumeration separately.
For the Music directory:
time ls -1 "/Volumes/24TB-B-FUSE/Music" >/dev/null
The entire 404-entry directory enumerated in:
2.728 seconds
So raw filesystem access was considerably more reasonable than Finder made it appear.
Actual movie playback also worked normally in my initial testing.
I am now testing this configuration as storage for a Jellyfin media server.
WHY I USED READ-ONLY MODE
Notice the:
-o ro
in my mount command.
That means exfat-fuse was NOT allowed to modify the 24 TB filesystem.
This made the experiment particularly useful.
Nothing was repaired.
Nothing was reformatted.
Nothing was recopied.
Nothing on the filesystem was rewritten.
The sequence was simply:
- Apple driver reads the exFAT filesystem → directories missing / Invalid argument.
- Unmount Apple's driver.
- Give the exact same partition to another exFAT implementation.
- Previously inaccessible directories immediately work.
For an archival media drive, read-only may also be desirable long-term. A media server such as Jellyfin can read the media while keeping its database, cache, thumbnails, metadata and transcoding files elsewhere.
WHAT THIS DEMONSTRATED
In my case, the evidence strongly indicates an interoperability/implementation problem with Apple's native exFAT handling rather than missing files or a failed copy.
The comparison was:
WINDOWS EXFAT IMPLEMENTATION
↓
Sees directories and files
APPLE NATIVE EXFAT IMPLEMENTATION
↓
Same filesystem
Missing/incomplete directories
"Invalid argument"
EXFAT-FUSE ON THE SAME MAC
↓
Same filesystem
Complete directories
Correct file counts
Files open and play
Nothing on the disk changed between the Apple-driver and FUSE-driver tests.
IF YOU ARE EXPERIENCING THIS
If you found this post because you have an exFAT disk where:
- Windows sees files/directories that macOS doesn't
- Finder shows folders as empty
- macOS sees only some entries in a large directory
- Terminal gives "Invalid argument"
- Disk Utility / fsck_exfat says the filesystem is OK
- The supposedly missing files still work normally in Windows
DO NOT IMMEDIATELY ASSUME YOUR DATA IS GONE.
And especially do not immediately reformat the disk simply because macOS can't see everything.
Try the disk under Windows first.
If Windows sees the supposedly missing data, consider testing the volume READ-ONLY using an independent exFAT implementation.
In my case, macFUSE + exfat-fuse 1.4.0 immediately exposed directories Apple's native exFAT implementation could not read.
I spent an absurd amount of time troubleshooting the disk, migration, filenames, filesystem integrity, macOS version and everything else because macOS successfully mounted the volume and showed MOST of it.
That partial failure was incredibly misleading.
The files weren't missing.
macOS's native exFAT implementation simply wasn't showing them.
