After upgrade to MacOS 15.0 Sequoia, "hdiutil: attach failed - no mountable file systems" error

[matthewjmiller1]

After upgrading to MacOS 15 (Sequoia), my VeraCrypt container file is no longer able to be mounted, giving the hdiutil error.

This file worked fine in MacOS 14 before the upgrade. This is the issue seen by others here but I don't have easy access to a non-MacOS 15 system to create a new container file to copy contents from the current container file.

I've tried both the OSXFUSE and FUSE-T VeraCrypt versions and the both give the same error (this is on a M3 MacBook).

When I mount, it gives the error:

hdiutil: attach failed - no mountable file systems

but shows Slot 1's info filled in in the GUI. No drive for it shows up under /Volumes.

If I click dismount, I get the error:

umount(/private/var/folders/f9/6v76cxn92g30tf6cng9_v0_40000gn/T/.veracrypt_aux_mnt1): Resource busy -- try 'diskutil unmount'

The only way I can get it to dismount at that point is:

macbook-air$ sudo lsof | grep verac
diskimage 6787               millers    4u      REG               26,4 104595456                   3 /private/var/folders/f9/6v76cxn92g30tf6cng9_v0_40000gn/T/.veracrypt_aux_mnt1/volume.dmg
macbook-air$ kill -9 6787
macbook-air$ sudo diskutil umount /private/var/folders/f9/6v76cxn92g30tf6cng9_v0_40000gn/T/.veracrypt_aux_mnt1/
Unmount successful for /private/var/folders/f9/6v76cxn92g30tf6cng9_v0_40000gn/T/.veracrypt_aux_mnt1/
macbook-air$

So it seems like some portion of the mount is succeeding, enough that there is a volume that needs unmounted, but obviously some portion of the mount is not working.

I can see this consistently if there are any logs or such I can collect. If there is some workaround available to mount the container that doesn't involve access to a non-MacOS 15 OS, that would be ideal.

Expected behavior

File can be mounted without error as it did in MacOS 14.

Observed behavior

hdiutil: attach failed - no mountable file systems error when attempting to mount the file.

Steps to reproduce

1. Have a working container file in MacOS 14.
2. Upgrade to MacOS 15.
3. Attempt to mount the container from (1).

Screenshots

Your Environment

Please tell us more about your environment

VeraCrypt version: 1.26.14 Operating system and version: MacOS 15.0

System type: MacBook Air, M3

[idrassi]

Thanks for the report.

There is already a long discussion about this issue on the SourceForge forums: https://sourceforge.net/p/veracrypt/discussion/general/thread/137169447e/?limit=25#0f38/ae3e

Long story short, macOS Sequoia introduced a compatibility issue with the exFAT filesystem that prevents it from accepting exFAT volumes created on Windows.

For now, users have worked around this by creating a new exFAT volume on Sequoia and copying data from the old volume to the new one. This new volume is also mountable on Windows.

I have already reviewed the information shared by other users and there is nothing that VeraCrypt can do to resolve this issue, since the actual mounting process works and it is the macOS kernel that rejects the exFAT filesystem.

Regarding the failure to dismount, the volume is locked by the system so we need a way to forcefully dismount it. I'm not sure yet how to achieve this from within VeraCrypt.

[matthewjmiller1]

If anyone else is stuck in a similar situation to me where they don't have easy access to a non-Sequoia system to mount their old ExFAT VeraCrypt file, I created the Dockerfile below that can be built and run using Docker Desktop on Sequoia to mount your ExFAT-based VeraCrypt file in a Linux container and then copy its contents to a new VeraCrypt file/mount that was created in Sequoia.

README.md

• Assume secure_info.hc is the old file with an ExFAT filesystem that cannot be opened by Sequoia and secure_info2.hc is a new, empy file that was created in Sequoia and can be mounted successfully there.

• Copy secure_info.hc and secure_info2.hc to the directory with the Dockerfile. The Dockerfile is hard-coded with these file names so it will need updated if you want to use different file names.

• Build, run, and access the container:

host$ export TAG=veracrypt

host$ docker build -t ${TAG} .
host$ docker run --privileged --name ${TAG} --rm -dit ${TAG}
host$ docker exec -it ${TAG} /bin/bash

• In the container instance, mount the old file, the new file, and copy the contents of the old file to the new file. Then, dismount the volumes. Note that this method will prompt for your password for each mount command, adjust accordingly if you use keyfiles or such. N.B.: this is only updates the new file in the container image, which is transient; see the next step for copying the updated file out of the container instance.

container# veracrypt -m=nokernelcrypto  --pim 0 --keyfiles "" --protect-hidden no --verbose secure_info.hc /vc_mnt/vc_old
container# veracrypt -m=nokernelcrypto  --pim 0 --keyfiles "" --protect-hidden no --verbose secure_info2.hc /vc_mnt/vc_new
container# cp -a /vc_mnt/vc_old/. /vc_mnt/vc_new/
container# veracrypt -d

• Copy the updated file out of the container to your local filesystem.

host$ docker cp veracrypt:/veracrypt_files/secure_info2.hc secure_info3.hc

At this point, secure_info3.hc is a file that contains the content from secure_info.hc and can be successfully mounted in Sequoia.

• Exit the container and stop the instance.

container# exit
host$ docker stop ${TAG}

Dockerfile

FROM ubuntu:24.04

ENV DEBIAN_FRONTEND=noninteractive
ENV INSTALL_DIR=/usr/local

RUN apt-get update && \
    apt-get -y install \
    build-essential \
    exfat-fuse \
    yasm \
    pkg-config \
    libwxgtk3.2-dev \
    libfuse-dev \
    libpcsclite-dev \
    git \
    wget \
    vim \
    ripgrep \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /git_repos
RUN git clone https://github.com/veracrypt/VeraCrypt.git
WORKDIR /git_repos/VeraCrypt/src
RUN make -j $(nproc)

ENV PATH="$PATH:/git_repos/VeraCrypt/src/Main"

WORKDIR /veracrypt_files
COPY secure_info.hc /veracrypt_files
COPY secure_info2.hc /veracrypt_files

WORKDIR /vc_mnt/vc_old
WORKDIR /vc_mnt/vc_new

WORKDIR /veracrypt_files

ENTRYPOINT ["/bin/bash"]

[idrassi]

For the record, there is indeed a bug in macOS Sequoia regarding exFAT volumes and disks. It has been reported to Apple since last year, but no fix has been released: https://discussions.apple.com/thread/255188289?sortBy=rank.

So, Apple officially doesn't seem to care about this, and the only solution is to create new exFAT volumes on macOS Sequoia.

Additionally, this article provides more details on the issue: https://appleinsider.com/articles/24/04/03/external-drive-support-in-macos-sonoma-is-partially-broken-and-its-probably-apples-fault. It mentions:

The implementations of the exFAT and MSDOS file systems on macOS have changed; these file systems are now provided by services running in user space instead of by kernel extensions. If an application has explicit checks or support for either the exFAT or MSDOS file systems, validate the application with those file systems and report any issues. (110421802)

So, the new exFAT implementation is indeed buggy.

[tobinq]

I have a similar problem under macos sequoia 15.6.1 with a hfs plus filesystem.

container and filesystem were created under macos maybe half a year ago. Then macos crashed while the container and filesystem were in active use few weeks ago and then i started to get this message too.

As i didnt know how to use fsck with veracrypt on macos (missing feature or RTFM?) i used "fsck.hfsplus -f /dev/dm-2" on a current ubuntu24 and was then able to mount the filesystem again under macos. BUT it will always only mount ONCE. Every (successful) umount and subsequent mount try later on macos it will result in the error "hdiutil: attach failed - Keine aktivierbaren Dateisysteme" which is the same message as in this issue but partly translated to german.

i tried fsck +mount on ubuntu again which worked but later realized that the fsck part is unneeded (it also didnt find anything to repair each time). To actually mount the volume again under macos i need only to mount and umount the hfsplus filesystem under linux once. No fsck needed before i am able to mount it under macos for ONE single time again. this is reproduceable at least with this container and filesystem (i have only that one and its too large to just copy it on a free usb drive).

My guess is that macos somehow considers a not cleanly umounted filesystem as not mountable, until someone actually mounts and umounts it again. As of some other bugs i see under macos, that feel like caused by race conditions, part of my guess is that apple excessively tries to decouple things to make the "speed" experience "better" while probably (just my guess) reporting a false "done with umounting" back to the process that requested it, only to flush the cache / write the last bits of umounting and clearing the "this filesystem was mounted previously and if found with this bit set, it was not umounted at all" at a somewhat later time, maybe only milliseconds later. if this guess is the case, then a (configureable) delay in veracrypt between umounting and actually closing the encryption container should solve my problem.

However the final solution for the bugs i have to deal with in macos, is to simply not use macos.

I report it here because i dont need a separate issue and wont be able to tell if the problem is solved anyway, and it seems somewhat related to this issue - though not necessarily - but my experiences and guess might be a hint for a possible workaround (mount/umount under different os + delay between umount and closing the container on macos) . and it should be also easy to test.

UPDATE: regarding easy to do tests: i tried mounting the volume readonly (which is not suitable for my daytoday usage) and it was indeed mountable multiple times in a row without errors. turning off the readonly mount options, the volume showed the error immediately after mounting rw, umounting and then trying to mount again.