TimeOut at VeraCrypt::FuseService::Mount:727

[majo-z]

I experience a similar issue as described in #1757 with the latest FUSE-T version.
VeraCrypt 1.26.24 works fine.

Environment

• Apple silicon M4, macOS 26.5.1
• FUSE-T 1.2.7, GitHub Release
• VeraCrypt 1.26.29, GitHub Release

Tests

$ export PKG_CONFIG_PATH="/Library/Application Support/fuse-t/pkgconfig:$PKG_CONFIG_PATH"
$ pkg-config --modversion fuse-t
1.2.7

$ ls -l "/Library/Application Support/fuse-t/bin"
lrwxr-xr-x  1 root  wheel        14 14 Jun 17:34 go-nfsv4 -> go-nfsv4-1.2.7
-rwxr-xr-x  1 root  wheel  20342560  3 Jun 13:11 go-nfsv4-1.2.7

$ "/Library/Application Support/fuse-t/bin/go-nfsv4" --help          
Usage of /Library/Application Support/fuse-t/bin/go-nfsv4:

$ "/Library/Application Support/fuse-t/bin/go-nfsv4" --backend string       
fuse-t nfsv4 server: Copyright (c) 2022-2025 Alex Fishman All Rights Reserved
version:	 1.2.7

/Library/Application Support/fuse-t/cfg/fuse-t.ini contents:

[Default]
;debug=false
;nfc=false
;readonly=false
;namedattr=true
;attrcache=true
;nobrowse=false
;rwsize=0
;noatime=false
;nomtime=false
;location=fuse-t
;backend=nfs
;bonjour=false
;logfile=$HOME/Library/Logs/fuse-t/fuse-t.log

[idrassi]

Thanks for the detailed report.

I can't reproduce this on my Apple Silicon M1 test machine running macOS 26.5.1. In my setup, VeraCrypt is explicitly enabled under "Privacy & Security for:

• Local Network
• Full Disk Access

Please check these permissions first. This is important for the FUSE-T build because FUSE-T uses a local network filesystem backend internally, and if macOS blocks VeraCrypt from using that local network path, the auxiliary FUSE-T mount may never expose /control, leading to the timeout at VeraCrypt::FuseService::Mount:727.

After enabling these permissions, please quit VeraCrypt completely and start it again before retrying.

If the issue still reproduces after confirming these permissions, please share:

otool -L /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt | grep fuse
ls -l /usr/local/lib/libfuse-t*
ls -l "/Library/Application Support/fuse-t/lib"/libfuse-t*
mount | grep veracrypt_aux_mnt
ps aux | grep -E 'go-nfsv4|fuse-t' | grep -v grep
tail -200 "$HOME/Library/Logs/fuse-t/fuse-t.log"

The difference between VeraCrypt 1.26.24 and 1.26.29 is relevant here: 1.26.24 used FUSE-T's default backend, while 1.26.29 intentionally uses backend=smb for the internal auxiliary mount to avoid the NFS/Network Volumes privacy problem seen in earlier reports #1667/#1579.

[Christian-SC26]

Had the same problem - for me, it happens when I unmount my disk through Finder. And only a full system restart fixes it.

[idrassi]

@Christian-SC26
Thanks, this is useful information. This may be a different trigger than the initial mount time timeout: using Finder to eject the mounted VeraCrypt disk can bypass VeraCrypt normal cleanup path for the internal FUSE-T auxiliary mount.

VeraCrypt 1.26.29 changed the FUSE-T auxiliary mount to use FUSE-T SMB backend. I'm investigating whether, on some systems, a failed SMB mount or a Finder-side eject can leave the internal FUSE-T backend process running without a visible mount point, which would explain why only a reboot clears the problem.

It would help if you reproduce the issue and before rebooting please share:

ps auxww | grep -E 'go-nfsv4|VeraCrypt|veracrypt_aux_mnt' | grep -v grep
mount | grep -E 'veracrypt_aux_mnt|fuse-t|smbfs|nfs'
hdiutil info
tail -300 "$HOME/Library/Logs/fuse-t/fuse-t.log"

Also please confirm whether the issue happens after unmounting from VeraCrypt itself or only after ejecting the mounted disk in Finder.

For now, with the FUSE-T build, please prefer unmounting from VeraCrypt rather than Finder while I investigate a more robust cleanup fix.

[majo-z]

Thanks for the detailed report.

I can't reproduce this on my Apple Silicon M1 test machine running macOS 26.5.1. In my setup, VeraCrypt is explicitly enabled under "Privacy & Security for:

• Local Network
• Full Disk Access

Please check these permissions first. This is important for the FUSE-T build because FUSE-T uses a local network filesystem backend internally, and if macOS blocks VeraCrypt from using that local network path, the auxiliary FUSE-T mount may never expose /control, leading to the timeout at VeraCrypt::FuseService::Mount:727.

After enabling these permissions, please quit VeraCrypt completely and start it again before retrying.

If the issue still reproduces after confirming these permissions, please share:

otool -L /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt | grep fuse
ls -l /usr/local/lib/libfuse-t*
ls -l "/Library/Application Support/fuse-t/lib"/libfuse-t*
mount | grep veracrypt_aux_mnt
ps aux | grep -E 'go-nfsv4|fuse-t' | grep -v grep
tail -200 "$HOME/Library/Logs/fuse-t/fuse-t.log"
The difference between VeraCrypt 1.26.24 and 1.26.29 is relevant here: 1.26.24 used FUSE-T's default backend, while 1.26.29 intentionally uses backend=smb for the internal auxiliary mount to avoid the NFS/Network Volumes privacy problem seen in earlier reports #1667/#1579.

Hello,
Thank you for your response.

I found the culprit. The SMB client was set to session & share encryption. It's working now.

However, I still have a problem. Maybe I should open a new issue for this instead of continuing here.
The drive fails to eject after the VeraCrypt container is unmounted.
The nfsv4-1.2.7 / VeraCrypt instances keep hanging in Activity Monitor, even after VeraCrypt is fully closed.
The only solution is to force quit the processes and then eject the drive, or force eject the drive.
This again could be some issue on my side.