macOS: core-service + fuse-t server processes persist after dismount (stale Bonjour/Finder entries); fuse-t backend hardcoded to SMB, FSKit unusable

[morin-andrew]

Environment: macOS 26.6 (25G72), MacBook Air M1 (MacBookAir10,1),
VeraCrypt 1.26.29 (FUSE-T Build), fuse-t 1.2.7 (Homebrew cask).

Issue 1 - processes leak on dismount:
Each volume mount spawns root-owned "VeraCrypt --core-service" processes plus
one fuse-t server: /usr/local/bin/go-nfsv4 --namedattr=false --rwsize=262144
--dontbrowse=true --backend smb /private/tmp/.veracrypt_aux_mnt1
After dismounting the volume, these processes persist indefinitely. I observed
intact core-service + go-nfsv4 pairs from multiple earlier mount sessions
coexisting. Each surviving go-nfsv4 holds an SMB Bonjour registration, so each
new mount registers as fuse-t-1, fuse-t-2, etc., and Finder accumulates stale
"fuse-t" network entries. The leaked processes ignore SIGTERM (sudo pkill);
SIGKILL is required. Killing the core-service correctly tears down go-nfsv4,
consistent with fuse-t's documented design that the server exits when its
filesystem process dies - so the leak appears to be core-service not exiting
after the last dismount.

Repro: mount a file container, dismount it, repeat once, then run:
ps aux | grep -E 'go-nfsv4|core-service' | grep -v grep
dns-sd -B _smb._tcp local. (observe fuse-t, fuse-t-1, ...)

Issue 2 - backend hardcoded to SMB:
fuse-t 1.2.x supports a native FSKit backend on macOS 26+. With the FSKit
extension enabled (fskitd/fskit_agent running) and
/Library/Application Support/fuse-t/cfg/fuse-t.ini set to backend=fskit,
a fully fresh VeraCrypt start still launches go-nfsv4 with an explicit
"--backend smb", overriding both fuse-t's documented default (NFS) and the
ini. VeraCrypt resolves the system libfuse-t 1.2.7 at /usr/local/lib (verified
via otool -L / LC_RPATH), so this is not a stale bundled library. There is
currently no way for users to select the FSKit backend. Request: honor the
fuse-t.ini default or expose a backend setting.

Context: this setup produced repeatable kernel panics when sleeping with a
volume mounted: panic(...): busy timeout[1], (60s): multiple entries holding
the registry busy ... 'IOMediaBSDClient' @IOService.cpp:5986. Full panic log
available (can attach).

[mimoex]

I'm only a regular VeraCrypt user and not a developer of the project, but I did some investigation after reproducing this issue on my Mac.

I investigated this further and was able to reproduce the process/device-hold problem independently with a physical VeraCrypt volume.

Environment

• macOS 26.6.x
• Apple Silicon (MacBook Air M4)
• VeraCrypt built from commit b48e31f5b47da7d41025e3f0e02751675e15005a
• FUSE-T 1.2.7
• Physical VeraCrypt volume on a 1 TB USB SSD

What happens after VeraCrypt dismount

After dismounting the volume from the VeraCrypt GUI, the visible filesystem and auxiliary mount disappear normally.

For example:

mount | grep -Ei 'veracrypt|fuse-t|smbfs|veracrypt_aux'
# no output

and hdiutil info shows no attached image.

However, the FUSE-T/VeraCrypt processes remain alive.

In my reproduction, the remaining processes included:

VeraCrypt --core-service
go-nfsv4 ... --backend smb /private/tmp/.veracrypt_aux_mnt1
VeraCrypt --core-service

More importantly, lsof showed that the leaked processes still had the physical raw disk open:

$ sudo lsof -nP /dev/disk4 /dev/rdisk4

COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
go-nfsv4- 96407 root    3u   CHR   1,20  0t65536 785 /dev/rdisk4
VeraCrypt 96408 root    3u   CHR   1,20  0t65536 785 /dev/rdisk4

Because /dev/rdisk4 was still open, macOS Disk Utility could not eject the physical SSD.

If I killed the remaining VeraCrypt/FUSE-T processes first:

sudo pkill -KILL -f 'VeraCrypt'
sudo pkill -KILL -f 'go-nfsv4.*veracrypt_aux_mnt'

the raw-device holders disappeared, and the disk could immediately be ejected:

$ diskutil eject disk4
Disk disk4 ejected

The leaked VeraCrypt process is still inside fuse_main()

I also sampled the remaining VeraCrypt process after the GUI dismount.

Its main thread remained blocked inside FUSE-T for the entire sample:

fuse_main_real_compat25
  fuse_main_common
    fuse_loop_mt
      fuse_session_loop_mt
        fuse_sem_wait
          _pthread_cond_wait
            __psynch_cvwait

A FUSE worker thread was also still waiting in the receive path:

fuse_session_receive_buf
  fuse_ll_receive_buf
    fuse_chan_recv
      fuse_kern_chan_receive
        ...
          recvfrom

This suggests that although the macOS-visible mount has disappeared, fuse_main() has not returned.

That matters because VeraCrypt releases the mounted volume from the FUSE destroy path:

static void fuse_service_destroy (void *userdata)
{
    try
    {
        FuseService::Dismount();
    }
    ...
}

and FuseService::Dismount() calls CloseMountedVolume().

If the FUSE session never terminates, the backing physical device can remain open.

A/B test: removing only the forced SMB backend

I then tested the backend=smb option specifically.

The current FUSE-T path contains:

#ifdef VC_MACOSX_FUSET
    args.push_back ("-o");
    args.push_back ("backend=smb");
    args.push_back ("-o");
    args.push_back ("nonamedattr");
    args.push_back ("-o");
    args.push_back ("rwsize=262144");
#endif

I removed only:

args.push_back ("-o");
args.push_back ("backend=smb");

while leaving nonamedattr and rwsize=262144 unchanged.

After rebuilding VeraCrypt with that minimal change, the same physical SSD could be:

1. mounted by VeraCrypt,
2. dismounted normally,
3. and then ejected normally from macOS Disk Utility.

So on this system:

forced backend=smb
    -> VeraCrypt/FUSE-T processes remain after dismount
    -> /dev/rdiskN remains open
    -> physical disk cannot be ejected

backend=smb not forced
    -> dismount completes
    -> raw device is released
    -> physical disk can be ejected normally

My test patch is here:

https://github.com/mimoex/VeraCrypt/tree/fix/macos-fuset-backend-selection

Commit:

mimoex@4fddeed

Why backend=smb was introduced

I also looked into the history of this option.

The forced SMB backend was introduced in:

250a488

as a workaround for #1667.

In #1667, the FUSE-T auxiliary mount sometimes failed to expose:

/tmp/.veracrypt_aux_mnt1/control

and VeraCrypt consequently failed during the early mount phase.

The maintainer stated that he could not reproduce the issue on his own M1 test machine. Based on source analysis and comparison with Cryptomator's FUSE-T integration, VeraCrypt was changed from FUSE-T's default NFS backend to an explicitly forced SMB backend.

However, the original reporter later reinstalled FUSE-T using Homebrew and reported that the problem disappeared and could no longer be reproduced.

So, as far as I can tell, the underlying cause of #1667 was never conclusively established.

This makes the current behavior particularly interesting:

#1667
default NFS backend
    -> intermittent auxiliary mount/control-file failure on one system
    -> root cause not conclusively established
    -> workaround: force SMB backend

current issue
forced SMB backend
    -> FUSE session may remain alive after VeraCrypt dismount
    -> raw backing device remains open
    -> physical disk cannot be ejected

Because FUSE-T now also supports backend configuration itself, I think it may be safer for VeraCrypt not to hardcode a particular backend and instead honor FUSE-T's configured/default backend.

That would also address the FSKit-selection problem described in this issue.

Possible relation to the sleep/wake kernel panic

I also observed a repeatable sleep/wake kernel panic with the physical disk in this stale state.

The panic contains:

busy timeout[1], (60s): 'IOMediaBSDClient'

The behavior I observed was:

VeraCrypt dismount
    -> raw device still held by leaked VeraCrypt/FUSE-T processes
    -> physical disk cannot be ejected
    -> sleep
    -> wake
    -> kernel panic

As a separate test, I killed the leaked VeraCrypt processes, successfully ejected the disk, and then put the Mac to sleep.

In that case, the Mac resumed normally without the crash.

After removing the forced backend=smb option, VeraCrypt also releases the disk sufficiently for Disk Utility to eject it normally after dismount.

This does not by itself prove that the SMB backend or the leaked FUSE session is the direct cause of the kernel panic, but the persistent raw-device hold and the IOMediaBSDClient busy-timeout panic appear to be related and warrant further investigation.