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

Abierto
  • ¿Algo no está bien?
#1,845 20 comentarios 7 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c, macos
Área
backend, operating-systems

Línea de trabajo

The report identifies two macOS issues: leaked core-service and go-nfsv4 processes after dismount, and the hardcoded SMB backend. Start by tracing VeraCrypt’s macOS mount and dismount paths and where it launches go-nfsv4 with --backend smb; inspect related tests, if present. Done means dismount cleans up the processes and the configured or selectable fuse-t backend is honored; verify with the repro commands in the issue.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

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).

Lenguaje dominante
C
Estrellas
11.7k
Forks
1.4k
Merge medio
1 d 1 h
PR fusionados (30 d)
28

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de veracrypt/VeraCrypt

Todos los issues de veracrypt/VeraCrypt

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.