Unable to open vol after upgrading to MacOS 27.0

[hansonchar]

I upgraded my M2 Macbook to MacOS 27.0 last night, and I have not been able to open the veracrypt vol since.

Expected behavior

I selected the encrypted volume, typed in the password and expected to see the volume to be loaded as usual.

Observed behavior

Instead, a failure error message popped up:

objc[2123]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

Steps to reproduce

1. Open Veracrypt app
2. Select the encrypted volume
3. Type in the password
4. Select "Mount"

Screenshots

Your Environment

Please tell us more about your environment

VeraCrypt version:

VeraCrypt 1.26.29.
Macfuse 5.4.0.

I tried both VeraCrypt_FUSE-T_1.26.29.dmg (together with fuse-t-macos-installer-1.2.7.dmg) and VeraCrypt_1.26.29.dmg. Both ended up with the same error.

Operating system and version:

macOS Golden Gate 27.0

27.0.0 Darwin Kernel Version 27.0.0: Tue Aug 11 21:02:16 PDT 2026; root:xnu-13432.1.9~1/RELEASE_ARM64_T8112 arm64

System type:

ARM 64, Apple silicon

[sfadeev]

As temp workaround it is possible to set env var before VeraCrypt run:

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

[bfleischer]

Please see #1863 and macfuse/macfuse#1193 for the investigation.

Setting OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES disables the Objective-C runtime’s safety check, but does not make the inherited framework state safe. The process can still crash when unmounting the volume, as reported in #1863.

The underlying issue is that libfuse inherits a poisoned state from VeraCrypt. Since macFUSE 5.3.0, libfuse relies on high-level macOS APIs that require valid framework state. Disabling the safety check does not repair that state. The underlying initialization and fork sequence should be addressed in VeraCrypt.

[raymundovr]

Experienced the same issue and have installed the FUSE-T version, as suggested in Veracrypt's website:

FUSE-T compatible version : VeraCrypt_FUSE-T_1.26.29.dmg (PGP Signature)
FUSE-T compatible version is recommended for Mac computers with Apple silicon.

Issue is solved and volumes are mounted normally.

[xylphe]

@raymundovr Which version of Veracrypt and macOS are you using?

[raymundovr]

@xylphe VeraCrypt_FUSE-T_1.26.29 (downloaded today from website) and Mac OS Golden Gate 27.0 (26A428)

[xylphe]

Confirming @raymundovr report on the same configuration as mine: VeraCrypt_FUSE-T_1.26.29 with fuse-t 1.2.7 on macOS 27.0 (26A428), Mac14,9 (M2 Pro), mounts and unmounts normally over two cycles. The macFUSE build (5.4.0) still fails as described above.

This is consistent with the analysis in macfuse/macfuse#1193: libfuse has relied on higher-level macOS APIs since macFUSE 5.3.0, which require valid framework state, whereas FUSE-T uses a fork of the older osxfuse libfuse and a separate server process. The root cause in VeraCrypt's initialization and fork sequence is unchanged, FUSE-T just doesn't hit it.

Note for anyone switching: the FUSE-T build leaks a go-nfsv4 server process on every unmount (#1879 ), so this is a workaround, not a fix.

[heinz-goetz]

I opened #1887 with a fix based on @bfleischer's PCSC analysis: PC/SC is now initialized lazily instead of in a static constructor before main(). With it, the core service fork() happens single-threaded again, and on macOS 27.0 / macFUSE 5.4.0 I get 30/30 clean mount/unmount cycles with no crash reports and no OBJC_DISABLE_INITIALIZE_FORK_SAFETY workaround. This also resolves the unmount SIGSEGV from #1863. Details and measurements are in the PR. Testing with a real EMV card reader would be appreciated, as I don't have one.