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.

[91koff]

Hello,

It looks like I have the same problem here.

Environment

• VeraCrypt 1.26.29 (FUSE-T build)
• Apple Silicon M1 Max
• macOS 26.5.2 (25F84)
• FUSE-T 1.27

How to reproduce

1. Connect an external SSD drive.
2. Launch VeraCrypt.
3. Select a VeraCrypt volume file located on the SSD drive.
4. Mount the volume.
5. Unmount the VeraCrypt volume by pressing the Unmount button in VeraCrypt.
6. The VeraCrypt container is successfully unmounted.
7. Press Eject on the SSD drive icon.
8. macOS cannot eject/unmount the external SSD drive.

Diagnostics

➜  ~ lsof -l /Volumes/X
COMMAND    PID     USER   FD   TYPE DEVICE     SIZE/OFF  NODE NAME
go-nfsv4- 9623      501    4u   REG   1,24 107374182400 96160 /Volumes/X/vera
VeraCrypt 9624      501    4u   REG   1,24 107374182400 96160 /Volumes/X/vera

Where X is the SSD drive name, and vera is the VeraCrypt volume file name on the external SSD drive.

Workaround

1. Kill the listed PIDs.
2. Eject the SSD drive.

[chimbori]

VeraCrypt has started leaving a lot of processes hanging around after the UI or CLI has terminated.

Killing all these processes (force-quit on MacOS) helps get rid of the error.

[umerf52]

Facing the same issue. Cannot decrypt encrypted volume.
Apple M1 Pro
macOS 26.5.2 (25F84)
VeraCrypt 1.26.29 (installed using brew)
macFUSE 5.3.3

[retrowiseninja]

Same issue happening to me. Cannot decrypt encrypted volume.
Apple M4
macOS 26.5.2
VeraCrypt 1.26.29
macFUSE 5.3.3

[smowggyayy]

Same for me. Not able to decrypt encrypted volume. Same errors as the screenshots above:

Apple M2 Silicon.
MacOS 26.5.1
Veracrypt 1.26.29
MacFUSE 5.3.3

I gave Veracrypt Full Disk Access but i couldn't enable Local Network as Veracrypt is not there.

FIX: What did work for me was uninstalling MacFUSE and installing the FUSE-T compatible version: VeraCrypt_FUSE-T_1.26.29.dmg
Now i can create volumes, move my files around, encrypt and decrypt, etc.

[retrowiseninja]

Same for me. Not able to decrypt encrypted volume. Same errors as the screenshots above:

Apple M2 Silicon. MacOS 26.5.1 Veracrypt 1.26.29 MacFUSE 5.3.3

I gave Veracrypt Full Disk Access but i couldn't enable Local Network as Veracrypt is not there.

**FIX**: What did work for me was uninstalling MacFUSE and installing the FUSE-T compatible version: VeraCrypt_FUSE-T_1.26.29.dmg Now i can create volumes, move my files around, encrypt and decrypt, etc.

The fix indeed allows me to encrypt and decrypt

[8my25kg4y9-hub]

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.

I face the same problem after creating a VeraCrypt volume.
I'd really like to allow local network for VeraCrypt but my preferences screen does not list veracrypt as an app taking part in local network communication? It is listed in full disc access though.

What else could I do?

[alavela]

Facing the same issue. Cannot decrypt encrypted volume. Apple M1 Pro macOS 26.5.2 (25F84) VeraCrypt 1.26.29 (installed using brew) macFUSE 5.3.3

Same versions, same issue for me. Not clear if the problem is in VeraCrypt or macFUSE.

[smowggyayy]

Same versions, same issue for me. Not clear if the problem is in VeraCrypt or macFUSE.

Try switching out MacFuse for the Fuse-T version. This worked for me.

[chrisfcarroll]

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.

Although Settings offers a “+” button to add VeraCrypt to Full Disk Access, there is no “+” button for local network access, and I get no pop-up asking me to grant permission. So I think I'm stuck on granting Veracrypt local network access.

VeraCrypt 1.26.29 (FUSE-T build)
Tahoe 26.5.2 on Apple M1.