diskutil does not recognise File System (but mount point works)

[Haravikk]

Very strange issue, but sometimes when I mount a dataset it seems to mount in a strange state whereby diskutil doesn't detect file system details — the mount point itself works fine (I can access data, write to it etc. without any issues) but this has some knock-on effects such as macOS being unable to search the volume at all (mdutil -as won't even list it).

The issue is strange because it's inconsistent, sometimes it just happens, but I've yet to find any kind of pattern as to why it happens when it does, as after restarting it may be fine again. For example, here is the output for an affected mount point:

% diskutil info disk10s21
   Device Identifier:         disk10s21
   Device Node:               /dev/disk10s21
   Whole:                     No
   Part of Whole:             disk10

   Volume Name:               Not applicable (no file system)
   Mounted:                   Yes
   Mount Point:               /Volumes/Users/haravikk/Documents/Resources
   File System:               None

   Partition Type:            ZFS Dataset
   OS Can Be Installed:       No
   Media Type:                Generic
   Protocol:                  Disk Image
   SMART Status:              Not Supported
   Disk / Partition UUID:     652C0FEC-48FB-3B7A-AE68-E50AAAC38994
   Partition Offset:          0 Bytes (0 512-Byte-Device-Blocks)

   Disk Size:                 6.9 TB (6940667150336 Bytes) (exactly 13555990528 512-Byte-Units)
   Device Block Size:         512 Bytes

   Media OS Use Only:         No
   Media Read-Only:           No
   Volume Read-Only:          Not applicable (no file system)

   Device Location:           Internal
   Removable Media:           Fixed

   Solid State:               Info not available

Note File System reads as None and Volume Name and Volume Read-Only as Not applicable (no file system) despite the dataset being mounted and otherwise usable, it just has information unavailable. For comparison, here is a dataset mounted without any issue:

% diskutil info disk10s5 
   Device Identifier:         disk10s5
   Device Node:               /dev/disk10s5
   Whole:                     No
   Part of Whole:             disk10

   Volume Name:               Downloads
   Mounted:                   Yes
   Mount Point:               /Volumes/Users/media/Downloads

   Partition Type:            ZFS Dataset
   File System Personality:   ZFS
   Type (Bundle):             zfs
   Name (User Visible):       ZFS Dataset

   OS Can Be Installed:       No
   Media Type:                Generic
   Protocol:                  Disk Image
   SMART Status:              Not Supported
   Volume UUID:               7A9048AF-471C-3835-8279-E9F027561713
   Disk / Partition UUID:     7A9048AF-471C-3835-8279-E9F027561713
   Partition Offset:          0 Bytes (0 512-Byte-Device-Blocks)

   Disk Size:                 6.9 TB (6940667150336 Bytes) (exactly 13555990528 512-Byte-Units)
   Device Block Size:         512 Bytes

   Volume Total Space:        871.9 GB (871920074752 Bytes) (exactly 1702968896 512-Byte-Units)
   Volume Used Space:         492.6 GB (492601122816 Bytes) (exactly 962111568 512-Byte-Units) (56.5%)
   Volume Free Space:         379.3 GB (379318951936 Bytes) (exactly 740857328 512-Byte-Units) (43.5%)
   Allocation Block Size:     512 Bytes

   Media OS Use Only:         No
   Media Read-Only:           No
   Volume Read-Only:          No

   Device Location:           Internal
   Removable Media:           Fixed

   Solid State:               Info not available

Note that it correctly shows a volume name, and instead of File System it identifies a File System Personality and type, along with additional details such as the volume sizes.

You can likewise see some missing information in the listing:

% diskutil list disk10   
/dev/disk10 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +6.9 TB     disk10
   1:                ZFS Dataset Drop Box                6.9 TB     disk10s1
   2:                ZFS Dataset Drop Box                6.9 TB     disk10s2
   3:                ZFS Dataset Drop Box                6.9 TB     disk10s3
   4:                ZFS Dataset Drop Box                6.9 TB     disk10s4
   5:                ZFS Dataset Downloads               6.9 TB     disk10s5
   6:                ZFS Dataset Jellyfin Metadata       6.9 TB     disk10s6
   7:                ZFS Dataset Movies                  6.9 TB     disk10s7
   8:                ZFS Dataset Music                   6.9 TB     disk10s8
   9:                ZFS Dataset Plex Metadata           6.9 TB     disk10s9
  10:                ZFS Dataset                         6.9 TB     disk10s10
  11:                ZFS Dataset Site Backups            6.9 TB     disk10s11
  12:                ZFS Dataset VMs                     6.9 TB     disk10s12
  13:                ZFS Dataset Dungeondraft            6.9 TB     disk10s13
  14:                ZFS Dataset Games                   6.9 TB     disk10s14
  15:                ZFS Dataset Downloads               6.9 TB     disk10s15
  16:                ZFS Dataset Kenku FM                6.9 TB     disk10s16
  17:                ZFS Dataset                         6.9 TB     disk10s17
  18:                ZFS Dataset                         6.9 TB     disk10s18
  19:                ZFS Dataset Downloads               6.9 TB     disk10s19
  20:                ZFS Dataset Movies                  6.9 TB     disk10s20
  21:                ZFS Dataset                         6.9 TB     disk10s21
  22:                ZFS Dataset                         6.9 TB     disk10s22

While everything is listed as ZFS Dataset only some have names, and the datasets without names are those that won't show as a "proper" file system despite otherwise functioning as expected. There are no obvious differences in settings between affected datasets (and like I say, it's inconsistent, so doesn't seem to be a setting issue as such, sometimes they'll mount without issue, other times they do this).

I'm running zfs-2.3.0-1 on macOS Sequoia 15.7.2 (24G325).

My only theory is that it has something to do with the macOS file system integration, and how it exposes file system details?

[lundman]

It could also be a race, if macOS is querying OpenZFS very early in the mount process, and sometimes gets in before OpenZFS is ready to reply. Those aren't fun to find mind you. If you wanted to see if you can get more information, set zfs_flags to "1" (via sysctl) and use the "log stream" or "log show" command to print out OpenZFS debug log real-soon-after it happens. It might print out a call failing.

[Haravikk]

Is there any way to force a dataset to appear to diskutil as if it were ejected without exporting the entire pool? It seems like once a dataset has been mounted its device ID becomes permanent even if I unmount and remount it (including if I mount other datasets in between). If I could "eject" without remounting that might help force diskutil to re-assess the device.

I'll try with zfs_flags=1 as soon as I can, I only restart periodically so it's going to be a case of me enabling it, mounting my datasets and seeing if any get into this weird state. That it's so inconsistent is annoying, as it could be a while before I managed to catch it, I'll update as soon as I can.

[lundman]

Ah if re-mounting doen't work, then it isn't a race, at least not in the mount part...

[Haravikk]

So I finally managed to catch this happening after setting flags to 1 but my filter on log stream didn't catch anything interesting so I'm afraid I've had to go nuclear on grabbing logs via log show, so the attached file is pretty long despite being limited to the minute during which the mounts took place.

In this case the affected dataset is disk11s17 mounted at /Volumes/Users/haravikk/Applications/Developer, to try to help you find relevant entries. One message that stood out to me was:

2025-12-07 08:26:20.479 Df diskarbitrationd[142:5741] [com.apple.DiskArbitration.diskarbitrationd:default] probed disk, id = /dev/disk11s17, with zfs, failure.

I'm guessing that's the point at which the view for diskutil becomes incorrect, but there's nothing immediately around that message that strikes me as a cause. Here's the diskutil info output in case that helps:

diskutil info disk11s17
   Device Identifier:         disk11s17
   Device Node:               /dev/disk11s17
   Whole:                     No
   Part of Whole:             disk11

   Volume Name:               Not applicable (no file system)
   Mounted:                   Yes
   Mount Point:               /Volumes/Users/haravikk/Applications/Developer
   File System:               None

   Partition Type:            ZFS Dataset
   OS Can Be Installed:       No
   Media Type:                Generic
   Protocol:                  Disk Image
   SMART Status:              Not Supported
   Disk / Partition UUID:     C9FF2240-448D-3D66-97D6-80371EC81F92
   Partition Offset:          0 Bytes (0 512-Byte-Device-Blocks)

   Disk Size:                 6.9 TB (6940667150336 Bytes) (exactly 13555990528 512-Byte-Units)
   Device Block Size:         512 Bytes

   Media OS Use Only:         No
   Media Read-Only:           No
   Volume Read-Only:          No (no file system)

   Device Location:           Internal
   Removable Media:           Fixed

   Solid State:               Info not available

Since I had to get messages retroactively the command I used was:

log show --style compact --start "2025-12-07 08:26:00" --end "2025-12-07 08:27:00"

Let me know if there's anything I should add to future attempts to narrow it down more!

log.txt.zip

[lundman]

, with zfs, failure.

Heh how useful macOS. So yeah, clearly something does go wrong sometimes, but is it macOS failing, or are we returning failure. So that is tricky. I believe diskutil mostly just calls zfs.util to figure out what to do with it, possibly that is cooked. Could wrap it in a bash script that dumps out result codes etc

[Haravikk]

I do wonder if it could still be a race condition of some kind because I do tend to mount several datasets in batches — basically I have a launch agent that mounts datasets for a user account when it logs in (using credentials in the user's keychain), and each account usually has at least two.

As for the issue persisting, I think maybe it's just because the disk identifiers don't seem to be reused — when I unmount and remount an affected dataset it gets the same device ID (i.e- if I unmount a dataset under disk11s17and remount, it seems to go back to disk11s17), even when I try remounting in a different order (not always feasible since some are nested). So I'd guess diskutil/diskarbitrationd/whatever isn't requesting details again on a remount which is why it persists?

I'm going to add a short delay to my launch-agent script, and try to remember to check it for a few days and let you know if that makes any difference, as maybe the problem is trying to get info for two devices at once?

[Haravikk]

Adding a 5 second delay before each zfs mount definitely seems to help — I haven't noticed this issue on any other device IDs, however I'm weirdly still seeing disk11s17 being affected. Without the delay I would sometimes get this issue on lower partition IDs.

Because I use several user accounts, most of which have their own datasets (unlocked and mounted on login, unmounted and locked after logout) the dataset that gets assigned to the device ID can differ between restarts, which is likely why I haven't noticed this issue all the time, as it's very noticeable with any dataset I search (as all forms of Finder search stop working, including non-Spotlight search).

I'm at a complete loss as to why that ID might be affected more though, so it may just be a coincidence, but I've definitely seen this issue most often on that ID, and only infrequently on lower IDs (not at all after adding the delay).

Update: I can confirm it's just a coincidence, I just got it to occur for disk11s18 and not disk11s17 (which is fine) but I'm still at a total loss what might be different between when it works and when it doesn't, and why it's so inconsistent. Some kind of race condition does still seem reasonable, I think the persistence must have something to do with how diskutil decides whether to check a new device (or if it sees it as already checked)?