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

Đang mở
  • Có gì không ổn?
#1,845 20 bình luận 7 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c, macos
Lĩnh vực
backend, operating-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
C
Star
11.7k
Fork
1.4k
Merge trung bình
1 ngày 1 giờ
Pull request đã merge (30 ngày)
28

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của veracrypt/VeraCrypt

Tất cả issue của veracrypt/VeraCrypt

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.