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

Have a working container file in MacOS 14.
Upgrade to MacOS 15.
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

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.

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"]

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.

veracrypt / VeraCrypt