macOS Tahoe appears to ignore /etc/fstab ro and noauto — findings and workaround
I encountered what appears to be a regression in macOS Tahoe where Disk Arbitration no longer honors ro and noauto policies in /etc/fstab for external volumes.
I am posting my findings here both to see whether others can reproduce the issue and to document a workaround, particularly for anyone using macOS for disk recovery or other workflows where preventing writes is important.
The problem
A configuration such as:
UUID=<volume-uuid> none exfat noauto
does not prevent the volume from automatically mounting.
Similarly:
UUID=<volume-uuid> none exfat ro
does not result in a read-only mount.
I also tested:
UUID=<volume-uuid> none exfat ro,noauto
with the same problem.
This configuration worked for me before upgrading from macOS Sequoia to Tahoe.
I initially suspected this might be related to Tahoe's newer exFAT/FSKit path, but testing APFS produced the same general behavior. It therefore appears to be broader than exFAT alone.
/etc/fstab itself is being parsed correctly
I tested the libc fstab interface using getfsent().
For example, an entry containing noauto is returned as:
spec=UUID=<volume-uuid> | file=none | vfstype=exfat | mntops=noauto | type=rw
So this does not appear to be a simple malformed-fstab problem.
Tracing also shows diskarbitrationd accessing /etc/fstab.
What Disk Arbitration is doing
Unified logs from an affected exFAT mount show the filesystem being successfully probed, followed by Disk Arbitration mount approval callbacks.
After approval, the reported mount options are:
Mount options nodev,noowners,nosuid
and the volume is then mounted successfully.
The ro policy expected from /etc/fstab is notably absent from those mount options.
Direct read-only mounting still works
The filesystem itself is capable of being mounted read-only.
For example, for exFAT:
sudo mkdir -p /Volumes/Exchange sudo mount_exfat -o rdonly /dev/diskXsY /Volumes/Exchange
This produces a genuinely read-only filesystem; a write test fails as expected.
So at least in my testing, the problem appears to be associated with the normal Disk Arbitration mounting path rather than an inability of the filesystem to support read-only mounting.
A working noauto workaround
Disk Arbitration still supports mount approval callbacks.
I tested a small client using:
DAApprovalSessionCreate DARegisterDiskMountApprovalCallback DADissenterCreate
The callback checks the volume UUID against /etc/fstab.
If the corresponding entry contains noauto, it returns:
kDAReturnNotPermitted
This successfully prevents the volume from mounting.
The test output looks like:
[BLOCK] mount request: /dev/disk5s1 [BLOCK] mount request: /dev/disk5s2
The volume remains unmounted.
Interestingly, this also blocks:
diskutil mount /dev/diskXsY
because diskutil mount goes through Disk Arbitration.
A direct filesystem mount such as mount_exfat, however, bypasses that approval request and can still be used to deliberately mount the filesystem read-only.
Why this matters
For an ordinary external disk, an unexpected automount may only be annoying.
For data recovery, forensic inspection, or a failing disk, the difference can be important.
If /etc/fstab says:
ro
I expect that policy to protect the source filesystem from writes.
Silently mounting the filesystem read-write instead means that the volume becomes available to Finder and other background services. That is exactly what I am trying to avoid when working with a recovery source.
For this reason, I would recommend verifying the actual mount state rather than assuming that an existing /etc/fstab ro entry is still protecting a disk after upgrading to Tahoe.
For example:
mount
or:
diskutil info /dev/diskXsY
should be used to confirm the resulting state.
Current workaround design
I am currently using a small compatibility helper that treats /etc/fstab as the source of truth:
/etc/fstab ↓ compatibility helper ↓ Disk Arbitration mount approval
The daemon side handles mount policy before Disk Arbitration can automatically mount the volume.
An explicit mount helper can then perform a direct filesystem mount with the options specified in /etc/fstab, including read-only mounting where required.
The intention is not to replace /etc/fstab, but to restore the behavior that was previously provided by the system.
Reproduction request
If anyone else is running macOS Tahoe, I would be interested to know whether you can reproduce this with either:
UUID=<uuid> none apfs noauto
or:
UUID=<uuid> none exfat noauto
and similarly with ro.
Please be careful when testing ro: use a disposable/test volume rather than a disk whose contents actually depend on remaining read-only.
I have also submitted this to Apple through Feedback Assistant.
Feedback ID: 24677522
I will update this post if Apple provides additional information or if a later Tahoe update changes the behavior.