User profile for user: bastus101
bastus101 Author
User level: Level 1
4 points

External APFS volume not mountable

Hi all,


I have a problem with my external SD card, which is unmountable, i.e. greyed out in Disk Utility. Only the APFS volume is, the containers and such are fine.

I use this 1TB SD card from Transcend as an storage extension of my MacBook M1 Pro.

I was told by now, that this is not a good solution because SD cards are relatively short lived...


What happened:

  • I updated to the latest Sonoma version about two weeks ago. I think it was 14.7.something.
  • Ever since the SD card was in this unmountable state


What I did (not exactly in that order; clustered it a bit according to topic):

  • I paniced a little... :'D I think (!), most of the data is backed up or can be retrieved from elsewhere, but I am not entirely sure and it would be an immense hassle... some things will probably be lost. (I will back up my data more often now..!)
  • did a lot of rebooting and replugging
  • I updated my system to Sequoia
  • I explored Disk Utility:
    • when I click 'mount', nothing happens
    • I ran 'First Aid': 
Checking the space manager.
error: spaceman cib out of order: 11, expected 19
Space manager is invalid.
The volume /dev/rdiskXsX with UUID 00000000-0000-0000-0000-000000000000 could not be verified completely.
File system check exit code is 8.
    • I could not find anything on this error message.. What does it inply? That the info on partitioning/"space" is corrupted?
  • I tried it from Recovery mode, no changes
  • I got help from the IT team at work, and they made a copy of the disk image. Now I can be more rough (although I also read that 'First Aid' is already quite rough...)
    • They were also unable to mount it from Windows (I guess because it's APFS) or Linux (which needed some package of course, because it's APFS)
  • I got into the Terminal and tried diskutil:
    • disk verification and disk mounting worked on both the physical and sythesized disks

volume verification and volume mounting didn't (also in readOnly); again with the same spaceman error, and:

Volume on diskXsX failed to mount
    • when I used 'repairDisk' on the Disk, it worked and repaired the partition map (but I was told that's only an aesthetic and makes sense because the harddrive the disk image was copied to was empty)
    • repairVolume didn't work, again with the same spaceman error
    • after hearing, that it might be internally password secured, I ran 'diskutil apfs unlock', which asked me for a passphrase, but I couldn't find anything in my keychain. I never locked it manually.
  • I tried out data recovery tools:
    • at the very beginning, I tried iBoysoft Data Recovery, it could find the files, but I feel reluctant to pay 100€ for an system update bug (?!)...
    • I looked into testDisk and tried it out. But I think it can inherently not recover files from APFS (?), as the option in the menu is missing. It did print an interesting message when analysing:
check_FAT: Unusual media descriptor (0xf0!=0xf8)
Warning: number of heads/cylinder mismatches 16 (FAT) != 1 (HD)
Warning: number of sectors per track mismatches 32 (FAT) != 1 (HD)
  EFI System                    XX     XXXXXXX     XXXXXX [EFI System Partition] [EFI]
  Apple APFS                XXXXXX XXXXX XXXXXXXXXXX
    • but why would it check_FAT anyways on an APFS filesystem..?


I think this was everything.. And I am absolutely out of ideas..!

Although, one thought I still had was resizing the container ('diskutil apfs resizeContainer' or so).. maybe that would do something about the space manager..? Just an uneducated guess...


Does anyone, maybe Apple, have any insights or tips for me?


(apart from backing up more, not using an SD card for storage expansion, and not update my system with external harddrives plugged in (although I believe, this should be accounted for in the update process...?!) :D)


Thanks a lot for reading through this super long "question" and maybe even for providing some guidance in these difficult times :')


Cheers!


[Edited by Moderator]

MacBook Pro 14″, macOS 15.5

Posted on Jun 20, 2025 4:12 PM

Reply
Question marked as Top-ranking reply
User profile for user: HWTech
HWTech
Community+ 2026
User level: Level 9
73,322 points

Posted on Jun 21, 2025 9:18 PM

bastus101 wrote:

What happened:
I updated to the latest Sonoma version about two weeks ago. I think it was 14.7.something.
• Ever since the SD card was in this unmountable state

FYI, I've seen numerous posts on this forum where people have reported not being able to access external drives after updating to macOS 15.5. There is a chance the same update was delivered to Sonoma as well although I think you are the first case.


• I tried out data recovery tools:
• at the very beginning, I tried iBoysoft Data Recovery, it could find the files, but I feel reluctant to pay 100€ for an system update bug (?!)...

If the data is important & it is not contained within your backups, then this may be the only option. Keep in mind if a deep/thorough scan is performed, then you will likely lose file/folder names & directory structure. If the files are found through a simple basic scan, then the file/folder names & directory structure will be retrieved as well.


• I looked into testDisk and tried it out. But I think it can inherently not recover files from APFS (?), as the option in the menu is missing.

It has been a few years since I last tried to use TestDisk on an Apple drive. Back then APFS still was not supported. I wasn't able to use it since none of the partition structures would work to allow recovery. Unfortunately the Apple drive structure is more complex than it is for non-Apple drives.


It did print an interesting message when analysing:
check_FAT: Unusual media descriptor (0xf0!=0xf8)
Warning: number of heads/cylinder mismatches 16 (FAT) != 1 (HD)
Warning: number of sectors per track mismatches 32 (FAT) != 1 (HD)
EFI System XX XXXXXXX XXXXXX [EFI System Partition] [EFI]
Apple APFS XXXXXX XXXXX XXXXXXXXXXX
• but why would it check_FAT anyways on an APFS filesystem..?

The FAT partition is due to a hidden EFI (aka ESP partition) that Disk Utility creates on all drives that it erases. The EFI/ESP partition is only needed on boot drives for UEFI computers. This is due to Apple "simplifying" things for their users.


Does anyone, maybe Apple, have any insights or tips for me?

FYI, Apple is not here on the forums. We are just other regular users such as yourself.


Run the following two Terminal commands so we can get some details about the drive layout on the SD card. Make sure to disconnect all other external drives so that only the information for the SD Card will be retrieved.


diskutil  list  external



For the next command, you need to get the device identifier for the physical SD Card. If the SD Card is the only external drive connected, then the first item in the previous output will contain the device ID for the SD Card. In the following command replace "diskX" with the actual device identifier for the physical SD Card:


sudo  gpt  show  diskX


This command will prompt you for your admin password. Nothing will appear on the screen as you type the password. Press the "Return" key to submit the password.


Either post a screenshot of the Terminal window or copy & paste the output here using the "Code Insertion" tool whose icon looks like "</>" on the forum editing toolbar. It will just make it easier to read the output as it will retain the spacing of the Terminal window.

View in context
13 replies
Question marked as Top-ranking reply
User profile for user: HWTech
HWTech
Community+ 2026
User level: Level 9
73,322 points

Jun 21, 2025 9:18 PM in response to bastus101

bastus101 wrote:

What happened:
I updated to the latest Sonoma version about two weeks ago. I think it was 14.7.something.
• Ever since the SD card was in this unmountable state

FYI, I've seen numerous posts on this forum where people have reported not being able to access external drives after updating to macOS 15.5. There is a chance the same update was delivered to Sonoma as well although I think you are the first case.


• I tried out data recovery tools:
• at the very beginning, I tried iBoysoft Data Recovery, it could find the files, but I feel reluctant to pay 100€ for an system update bug (?!)...

If the data is important & it is not contained within your backups, then this may be the only option. Keep in mind if a deep/thorough scan is performed, then you will likely lose file/folder names & directory structure. If the files are found through a simple basic scan, then the file/folder names & directory structure will be retrieved as well.


• I looked into testDisk and tried it out. But I think it can inherently not recover files from APFS (?), as the option in the menu is missing.

It has been a few years since I last tried to use TestDisk on an Apple drive. Back then APFS still was not supported. I wasn't able to use it since none of the partition structures would work to allow recovery. Unfortunately the Apple drive structure is more complex than it is for non-Apple drives.


It did print an interesting message when analysing:
check_FAT: Unusual media descriptor (0xf0!=0xf8)
Warning: number of heads/cylinder mismatches 16 (FAT) != 1 (HD)
Warning: number of sectors per track mismatches 32 (FAT) != 1 (HD)
EFI System XX XXXXXXX XXXXXX [EFI System Partition] [EFI]
Apple APFS XXXXXX XXXXX XXXXXXXXXXX
• but why would it check_FAT anyways on an APFS filesystem..?

The FAT partition is due to a hidden EFI (aka ESP partition) that Disk Utility creates on all drives that it erases. The EFI/ESP partition is only needed on boot drives for UEFI computers. This is due to Apple "simplifying" things for their users.


Does anyone, maybe Apple, have any insights or tips for me?

FYI, Apple is not here on the forums. We are just other regular users such as yourself.


Run the following two Terminal commands so we can get some details about the drive layout on the SD card. Make sure to disconnect all other external drives so that only the information for the SD Card will be retrieved.


diskutil  list  external



For the next command, you need to get the device identifier for the physical SD Card. If the SD Card is the only external drive connected, then the first item in the previous output will contain the device ID for the SD Card. In the following command replace "diskX" with the actual device identifier for the physical SD Card:


sudo  gpt  show  diskX


This command will prompt you for your admin password. Nothing will appear on the screen as you type the password. Press the "Return" key to submit the password.


Either post a screenshot of the Terminal window or copy & paste the output here using the "Code Insertion" tool whose icon looks like "</>" on the forum editing toolbar. It will just make it easier to read the output as it will retain the spacing of the Terminal window.

Reply
User profile for user: bastus101
bastus101 Author
User level: Level 1
4 points

Jun 25, 2025 4:44 AM in response to bastus101

Hi all,


thanks for your inputs and suggestions!


I gave up.. :'D


I had a call with apple support yesterday and after a few things that we tried, and a few things that I already did, they figured they couldn't help me with this. They agreed that this is probably an issue with the OS update procedure and will give feedback to the tech department.

They also offered me a discount for a data recovery service provider, but I would have to physically send it in.

This is taking too long and has been taking too long already, as it keeps me from producing music which is an important joy in my life.


I opted for DiskDrill now, because the free version found all the files and could retrieve the folder structure.

It is working for about 21h now and seems to be able to recover all the files.

And it's not a subscription service, so I have it for later as well.


Still, a super annoying situation and honestly ridiculous, if this is really a system update bug... But I also see the point, that I should've done all of this differently.

Could've used these 100€ for other things though :')


But, I learned a lot!


Cheers y'all!

Reply
User profile for user: bastus101
bastus101 Author
User level: Level 1
4 points

Jun 23, 2025 2:08 PM in response to HWTech

Thanks a lot HWTech for your thorough answer and explanations!


I should've probably mentioned, that I performed all of the diskutil stuff on the disk image copied to an external harddrive with nothing else on it. I don't see a change in the disk structure, following diskutil list, except, that the SD card is actually not an external, but an internal disk.


The output is the following:

start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6
          40      409600      1  GPT part - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
      409640  1954135984      2  GPT part - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
  1954545624           7
  1954545631          32         Sec GPT table
  1954545663           1         Sec GPT header

Both UUIDs are not the "empty" (000000-000- etc.) UUID from the First Aid output..



As for the rest:


FYI, I've seen numerous posts on this forum where people have reported
not being able to access external drives after updating to macOS 15.5.
There is a chance the same update was delivered to Sonoma as well
although I think you are the first case.

I briefly looked into rolling back, but it doesn't seem to be an option without reinstalling the OS as a whole.. meaning, cleansing the laptop..?


If the data is important & it is not contained within your backups,
then this may be the only option. Keep in mind if a deep/thorough scan
is performed, then you will likely lose file/folder names &
directory structure. If the files are found through a simple basic
scan, then the file/folder names & directory structure will be retrieved.

Yeah, I'm also kinda done with it, so I might just give in. But I'll get DiskDrill, as iBoysoft is another subscription service... And With DiskDrill, I at least get a full license, and it's still cheaper.


Either way, thanks for your effort though! Maybe I will still wait, or at least keep the disk image around to see if we can fix it, to help others.

Reply
User profile for user: HWTech
HWTech
Community+ 2026
User level: Level 9
73,322 points

Jun 23, 2025 2:43 PM in response to bastus101

bastus101 wrote:

Thanks a lot HWTech for your thorough answer and explanations!

I should've probably mentioned, that I performed all of the diskutil stuff on the disk image copied to an external harddrive with nothing else on it. I don't see a change in the disk structure, following diskutil list, except, that the SD card is actually not an external, but an internal disk.

The output is the following:
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
409640 1954135984 2 GPT part - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
1954545624 7
1954545631 32 Sec GPT table
1954545663 1 Sec GPT header

Both UUIDs are not the "empty" (000000-000- etc.) UUID from the First Aid output..


Did you mask out those values with X's? If so, those values are critical to knowing what type of partition & file system it is currently showing as in use. There is no personal information in the output of that command.


Reply
User profile for user: a brody
a brody
User level: Level 10
85,382 points

Jun 21, 2025 3:52 PM in response to bastus101

SD cards aren't really a good storage medium. The SD slot itself is far slower than USB 3, and I can tell you this much, it is not possible to make the SD card a truly bootable APFS partition. There could be bits on it that don't translate well compared to an external hard drive or SSD storage medium via USB or Thunderbolt. They may be fine for digital cameras, but general storage I found that SD design suffers greatly.

Reply
User profile for user: Matti Haveri
Matti Haveri
User level: Level 7
20,668 points

Jun 24, 2025 12:13 AM in response to Old Toad

I got 1TB OWC Envoy Pro Mini and it works great. 1010-1030 MB/s read/write via Mac mini 2018 USB-C ports and 460-450 MB/s via Mac mini USB-A ports (maybe the Mac mini USB-A port is the limiting factor. Tested with a 100 GB .dmg file and a stopwatch). It boots to High Sierra-Mojave-Sequoia OK and making a bootable USB macOS installer takes about 1-2 minutes while with my old 128 GB SanDisk thumbdrive it takes 20-30 minutes (that old SanDisk chokes with sustained large writes to unbearably slow).


I presumed it would be TLC or MLC. Before ordering I asked this from OWC support and they said it is SLC which AFAIK is the fastest, most durable, and least error-prone SSD type.


It suggested that OWC should advertise in the specs that Envoy Pro Mini is SLC because I'd avoid QLC SSDs like Samsung 860 QVO which use a small SLC as a cache which might saturate with sustained writes so the write speed might drop to HDD speeds.


https://www.howtogeek.com/444787/multi-layer-ssds-what-are-slc-mlc-tlc-qlc-and-mlc/


https://www.anandtech.com/show/13633/the-samsung-860-qvo-ssd-review


Tom's Hardware test briefly mentions it with "OWC Envoy Pro Mini remained the coolest, second-fastest overall and sports a solid metal shell. But its design is overly complicated, as is its setup process (which forces you to agree to a EULA, the primary problem with OWC's drive is price". I don't agree with the complicated design and IMO the setup process is fine with no EULA -- just erase the device via Disk Utility as APFS or in Windows with its built-in tools as NTFS or whatever you want. Yes, it is somewhat pricy but I wanted to support OWC for continued Mac support that other vendors might not always properly test.


https://www.tomshardware.com/best-picks/best-flash-drives


Reply

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

External APFS volume not mountable

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.
Learn more Sign up