External Hard Drive Read Only on Mac: Two Bits Decide

A drive that will not mount at all is a loud failure. A drive that mounts and then refuses to accept a file is a quiet one, and the quiet one is what people actually search for. Every guide I could find answers it the same way: your drive is NTFS, or your permissions are wrong, or you need First Aid. I have already taken the format answer apart from the other side, by building every filesystem macOS can create and measuring what each one costs. I ran the three states on a scratch volume today and found that diskutil info already knows which of those is true — it prints two separate read-only bits — and that none of the five guides I read tells you to look at the one that matters.

macOS tracks two read-only bits, not one

On this machine (Mac16,10, macOS 26.4.1 build 25E253), diskutil info prints these two lines for every volume:

   Media Read-Only:           No
   Volume Read-Only:          No

They are independent. Media Read-Only is the storage device refusing writes. Volume Read-Only is the mount refusing them. To see what each one looks like I built a 300 MB Journaled HFS+ disk image and attached the same file three ways:

Case	How	Media RO	Volume RO	touch	mount -uw
Normal	hdiutil attach a.dmg	No	No	OK	—
Mount flag	mount -uo rdonly /Volumes/ROTESTA	No	Yes	Read-only file system	works
Read-only media	hdiutil attach a.dmg -readonly	Yes	Yes	Read-only file system	Permission denied

The last two rows produce an identical symptom in Finder and an identical error in Terminal. They are not the same problem. In the middle row one command fixes it:

$ mount -uw /Volumes/ROTESTA
$ touch /Volumes/ROTESTA/ok.txt      # succeeds

In the bottom row the same command cannot:

$ mount -uw /Volumes/ROTESTA
mount_hfs: Permission denied
mount_hfs: error on mount(): error = -1.
mount: /Volumes/ROTESTA failed with 1

The line that tells you apart is the one nobody prints

Here is the part that made this worth writing. In both read-only rows the second line reads, byte for byte:

   Volume Read-Only:          Yes (read-only mount flag set)

Same text for the recoverable case and the unrecoverable one. The field that separates them is Media Read-Only. I pulled every read-only string out of the diskutil binary to check whether it has a better explanation hiding somewhere:

$ strings -a /usr/sbin/diskutil | grep -i read.only
   Media Read-Only:           %s
   Volume Read-Only:          %s%s
Yes (read-only mount flag set)

One parenthetical, total. For comparison the encryption field carries three — No (Encrypted at rest), Yes (no decryption required), Yes (unlock and decryption required). The tool is perfectly capable of explaining itself; it just does not do it here.

One more thing worth separating out: a freshly created non-system HFS+ volume mounts with Owners: Disabled (that is noowners). That produces permission errors on specific files, not Read-only file system on everything. If your error message says "you don't have permission", you are in the ownership case, not this one.

What five guides actually cover

I read the five top-ranking guides for this query that contain real procedures, and scored each on five items. Collected 2026-08-20; a sixth (help.macgasm.net) returned HTTP 403 and is excluded rather than guessed at.

Source	Updated	NTFS	Permissions	First Aid	Read-only media	Check diskutil info first
easeus.com	2026-06-30	yes	yes	yes	no	no
recoverit.wondershare.com	2026-08-13	yes	yes	yes	partial	no
iboysoft.com	2026-06-18	yes	yes	yes	no	no
macsecurity.net	2024-12-09	yes	partial	no	no	no
makeuseof.com	2023-10-18	yes	no	no	no	no

NTFS: 5 of 5. Read-only media: 0 of 5, with one partial that mentions cables and drive noises but never a write-protect switch or a dying disk. Telling the reader to run diskutil info before choosing a fix: 0 of 5. The one guide that touches Terminal uses diskutil list, which does not print either bit.

That is the gap. Three of the five open with permissions or First Aid — both of which are wasted moves when Media Read-Only is Yes, because the media is refusing the write before the file system is consulted.

The NTFS answer has expired on macOS 26.4.1

All five guides say, in the present tense, that macOS reads NTFS and cannot write to it. Three of them were updated in 2026. On this machine that sentence no longer describes anything, because the mount path is gone:

• /System/Library/Filesystems holds 16 filesystem bundles. ntfs.fs is the only one with no matching /sbin/mount_* helper.
• ntfs.fs declares FSImplementation = ["UserFS"]. exFAT and MS-DOS declare ["UserFS","kext"]. NTFS lost the kext axis.
• ntfs.util hardcodes /System/Library/Extensions/ntfs.kext. There are 747 kexts in that directory and it is not one of them. kmutil showloaded | grep -i ntfs returns nothing.
• The registered FSKit modules are exactly three — com.apple.fskit.exfat, com.apple.fskit.msdos, com.apple.fskit.ftp. There is no NTFS module.

Asking it to mount anyway shows the whole chain failing in order:

Executing: /usr/bin/kmutil load -p /System/Library/Extensions/ntfs.kext
The operation couldn't be completed. No such file or directory
ntfs.util: /sbin/kextload command failed: No such file or directory
mount: exec /Library/Filesystems/ntfs.fs/Contents/Resources/mount_ntfs
       for /private/tmp/roexp/mnt: No such file or directory
mount: /private/tmp/roexp/mnt failed with 72

Note the fallback path in that last line. /Library/Filesystems/ is where third-party drivers install themselves, which is exactly why Paragon and Tuxera still work while the built-in route does not. On this machine /Library/Filesystems contains one item, NetFSPlugins.

The limit of this measurement: I do not own an NTFS drive. I wrote an NTFS boot sector onto a scratch partition to force the probe, and the probe rejected it (exit 252) because a hand-built boot sector has no real metadata behind it. So I have shown that the driver chain is structurally absent, not that a real NTFS disk fails end to end. Those are different claims and I am not going to blur them.

Two causes I could not reproduce

Both of these get repeated constantly, and neither survived contact with this version:

• The exFAT dirty bit. I set VolumeFlags bit 1 at offset 0x6A in the exFAT boot sector — the field the spec excludes from the boot checksum, so no recomputation is needed. macOS remounted it read-write, touch succeeded, and the mount options showed fskit. Not reproduced.
• Corruption forcing a read-only demotion. I wrote 102,400 bytes of /dev/urandom over sectors 200–400 of an HFS+ volume. It mounted read-write and diskutil verifyVolume reported "appears to be OK", exit 0. I did not hit structures that matter; the demotion path stayed unproven either way.

I also could not test the APFS snapshot case: mount_apfs -s returns Operation not permitted (exit 77) without root, and this rig has no interactive sudo. Unmeasured, so unclaimed.

Before blaming the format, check whether you are in the 26.4 bug

There is a version-specific answer this year that predates every filesystem theory. Apple's own macOS 26.4 release notes carry a known issue, quoted by an Apple moderator on the developer forums: "HFS external media might fail to mount automatically. (168672160)" with the workaround "use CLI tool diskutil mount to attach the relevant disk device." The person who opened that thread described it as "External Raid hard drive read only mode After upgrade to 26.4."

AppleInsider collected reports on 2026-02-23 covering both APFS and HFS drives on 26.3, and was honest that the number of public complaints was small. And a long Apple Community thread that started as a Tahoe drive bug landed somewhere else entirely: the reporter found the drive mounted fine in Safe Mode, and later posters traced their own cases to ESET Cyber Security's device control blocking external volumes by default, plus vendor-bundled encryption apps from Samsung and LaCie. None of that is a format problem, and it rhymes with what I found when a drive on this rig kept dropping out and the cable turned out to be the variable. and reformatting would have destroyed the data for nothing.

The four commands to run first

diskutil info /Volumes/YourDrive | grep -i "read-only\|owners"
mount | grep YourDrive
mount -uw /Volumes/YourDrive        # only if Media Read-Only is No
diskutil mount /dev/diskNsM         # if it did not auto-mount at all

Read the first line's output as a two-bit answer. Both No means it is not read-only at all and you are looking at an ownership or permission problem. Media No plus Volume Yes means the mount flag is set and mount -uw will clear it. Media Yes is the one that ends the troubleshooting: the device is refusing writes, and no permission checkbox, First Aid pass or reformat reaches it. That is a write-protect switch, an enclosure fault, or a disk on its way out — Apple's Disk Utility documentation puts it bluntly: "If Disk Utility tells you the disk is about to fail, back up your data and replace the disk—you can't repair it."

If it comes to replacing it, the cheap capacity option most people land on is a 2 TB WD Elements (Amazon). I do not own one, so this is documentation rather than a use report, and the documentation carries a catch worth knowing before you buy: WD's own warranty table breaks the term by model-number suffix, not by product line. That listing's WDBU6Y0020BBK-WESN falls in the Americas 2-year row, while the same WDBU6Y with a -SESN or -CESN suffix sits in the 3-year row. I pulled that table apart in WD Elements vs My Passport.

Every measurement here was run on 2026-08-20 on one machine: Mac16,10 (M4), macOS 26.4.1 build 25E253, uptime 9d23:23. The read-only battery used hdiutil disk images in /tmp, not a physical drive, so the media bit was simulated with hdiutil attach -readonly rather than a failing disk. The NTFS section is an inventory of what is and is not installed, not a test against a real NTFS volume — I said so above and I will say it again here. The guide coverage table is a five-source count from 2026-08-20; a sixth source returned 403 and was left out. Some links are affiliate links; if you buy through one, this site earns a commission at no extra cost to you, and it lands on the public ledger.