macOS/FUSE-T: Terminate auxiliary FUSE service on dismount

[mimoex]

This PR fixes the FUSE-T service remaining alive after a VeraCrypt volume is dismounted on macOS.

It addresses the FUSE-T process/session leak reported in #1845.

Problem

With FUSE-T, the auxiliary mount can disappear while the corresponding VeraCrypt FUSE service is still running in fuse_main().

As a result, VeraCrypt may report that a volume has been dismounted even though the FUSE-T session is still alive and access to the decrypted volume has not been fully revoked.

This has two serious consequences.

1. The dismounted volume can become accessible again without a password

With the official VeraCrypt 1.26.29 FUSE-T build, the following sequence is reproducible:

1. Mount a VeraCrypt volume.
2. Open a .png file from the mounted volume in Preview.app, then close Preview.app.
3. Dismount the volume from the VeraCrypt GUI.
4. Select the same file from Preview's Open Recent menu.

The volume disappears from the VeraCrypt volume list and appears to have been dismounted. However, selecting the same file from Preview's Open Recent menu causes the stale FUSE-T session to reconnect, allowing the file to be opened without entering the VeraCrypt password.

If the remaining VeraCrypt/FUSE-T processes are terminated after dismount, this reconnection does not occur, and the file can no longer be opened from Open Recent without remounting the VeraCrypt volume normally.

This means that dismount does not reliably revoke access as long as the auxiliary FUSE service remains alive.

2. The leaked service can keep the raw device open across sleep/wake

For device-hosted volumes, the remaining VeraCrypt/FUSE-T processes may continue holding /dev/rdiskN or /dev/rdiskNsN after dismount.

This prevents normal device eject.

On affected systems, putting the Mac to sleep while the raw device remains held can also lead to a kernel panic after wake:

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

In testing reported in #1845, the panic stopped reproducing when the leaked VeraCrypt/FUSE-T processes were terminated before sleep.

Therefore, successful umount alone is not sufficient to complete the VeraCrypt dismount operation.

Solution

This patch explicitly terminates the corresponding auxiliary FUSE service during dismount.

The shutdown sequence is:

1. Read the FUSE service PID, SerialInstanceNumber, and slot number.
2. Verify that they match the volume being dismounted.
3. Request shutdown through the auxiliary FUSE filesystem.
4. Call fuse_exit() and fuse_unmount().
5. Wait until the matching service process has actually terminated before removing the auxiliary mount point.

The shutdown handler runs asynchronously after a short delay so that the FUSE write response can complete before the channel is closed.

Testing

Tested on a MacBook Air M4 running macOS 26.6.2 with FUSE-T 1.2.7.
I compared the official VeraCrypt 1.26.29 FUSE-T build with this patch using the same container and the same FUSE-T SMB backend.

VeraCrypt 1.26.29

After mounting the container, the mount-specific processes included:

VeraCrypt
go-nfsv4 ... --backend smb .../.veracrypt_aux_mnt1
VeraCrypt

The auxiliary filesystem was mounted through FUSE-T/SMB, and hdiutil info showed the VeraCrypt volume.dmg.

After dismounting from the VeraCrypt GUI, the auxiliary SMB mount disappeared and the volume.dmg was detached.

However, the mount-specific VeraCrypt processes and go-nfsv4 remained alive.

Thus, the macOS-visible mount was gone while the corresponding FUSE-T service was still running.

Patched build

I repeated the same test with the existing backend=smb behavior unchanged.

After dismounting from the GUI:

• the auxiliary SMB mount disappeared,
• the volume.dmg was detached,
• the mount-specific VeraCrypt service processes terminated, and
• the corresponding go-nfsv4 process terminated.

Only the VeraCrypt GUI processes that existed before the mount remained.

This confirms that explicitly terminating the auxiliary FUSE-T service fixes the leak without changing the FUSE-T backend selection.