Any updates on fixing the macos 26 issue?
You have a willing alpha tester here!
I started that ticket but it was closed and does not allow replies.
This is a gentle reminder to fix the issue, please.
Dear Valued Customers,
We have identified the issue where NetDrive could not mount drives on macOS 26 (Tahoe) and have prepared a test build that includes a fix.
You can download the test version from the link below:
Download NetDrive 3.18.835 (macOS)
Please install this version and let us know if it resolves the problem on your system. Your feedback will be very valuable for finalizing the official release.
We sincerely apologize for the inconvenience and greatly appreciate your help in testing this build.
Best regards,
NetDrive Support Team
Here is what I found:
When I first installed the test version over the previous version, it mounted some drives but not all.
I then did a complete uninstall, restart, and reinstall of the test version.
No drives will mount at all, just like the most recent released version.
Hello cmorris,
Thank you for testing the build and sharing the results. As you mentioned, initially some drives were able to mount, but after a clean uninstall and reinstall, none of the drives mount anymore. We understand how frustrating this must be.
To investigate further, could you please send us the log files generated with the test build?
To help us diagnose the issue:
- Please set the log level to VERBOSE
- Reproduce the problem.
- Afterward, please follow the instructions in the following link to send us the debug log file:
Please compress these into a single zip file and attach it. Our development team will review them immediately to work toward a fix.
We sincerely apologize for the continued inconvenience and truly appreciate your patience and assistance in helping us resolve this issue.
Best regards,
NetDrive Support Team
ND3 logs.zip (51.2 KB)
Here are the logs you requested
It did. Thanks.
To mount remote storage, the latest version uses a LaunchDaemon to start the kernel extension (kext) required for mounting. However, it appears that the kext is not being loaded after you log in.
Please run the following command in a terminal:
kextstat | grep ndfuse
If the kext is loaded, this command should display the ndfuse entry. For example:
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
258 0 0 0x1870 0x1870 com.bdrive.ndfuse.filesystems.ndfuse (3.17.0) 1C31DD58-86BC-311E-AA51-31AB85596BBA <7 5 4 3 1>
If nothing is listed, you can manually load the ndfuse kernel extension with the following command:
sudo kmutil load -p /Library/Filesystems/ndfuse.fs/Contents/Extensions/26/ndfuse.kext
Afterward, verify again with: kextstat | grep ndfuse
If the kext loads successfully, the issue is likely related to it not being loaded automatically at login. In that case, please ensure that Bdrive Inc. is allowed under System Settings → Login Items & Extensions.
Here is what I get:
Validating extension failed: Kext com.bdrive.ndfuse.filesystems.ndfuse v3.17.0 in executable kext bundle com.bdrive.ndfuse.filesystems.ndfuse at /private/var/db/KernelExtensionManagement/Staging/com.bdrive.ndfuse.filesystems.ndfuse.7m4OQN/ndfuse.kext:
Filesystem error: Other validation error: Error Domain=NSPOSIXErrorDomain Code=2 “No such file or directory”
Authenticating extension failed: Bad code signature
Thank you for the detailed feedback.
Looks like the failure is due to a missing/mismatched executable path and an invalid code signature. We’ll fix the bundle structure, re-sign with the proper kext-enabled certificate, notarize, and re-test.
Please run the following command and share the output with us:
codesign -dv --verbose=4 /Library/Filesystems/ndfuse.fs/Contents/Extensions/26/ndfuse.kext
Here you go:
MacBook-Pro-2:~ cmorris$ codesign -dv --verbose=4 /Library/Filesystems/ndfuse.fs/Contents/Extensions/26/ndfuse.kext
Executable=/Library/Filesystems/ndfuse.fs/Contents/Extensions/14.5/ndfuse.kext/Contents/MacOS/ndfuse
Identifier=com.bdrive.ndfuse.filesystems.ndfuse
Format=bundle with Mach-O universal (x86_64 arm64e)
CodeDirectory v=20200 size=580 flags=0x10000(runtime) hashes=12+3 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=961c607bb26a5019c6597e49364344c59522fb6e
CandidateCDHashFull sha256=961c607bb26a5019c6597e49364344c59522fb6e493a640d6cf8929f58e16441
Hash choices=sha256
CMSDigest=961c607bb26a5019c6597e49364344c59522fb6e493a640d6cf8929f58e16441
CMSDigestType=2
Page size=16384
CDHash=961c607bb26a5019c6597e49364344c59522fb6e
Signature size=8993
Authority=Developer ID Application: Bdrive Inc. (4M7G2HXTMV)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Sep 25, 2025 at 4:17:24 AM
Info.plist entries=20
TeamIdentifier=4M7G2HXTMV
Sealed Resources version=2 rules=13 files=0
Internal requirements count=1 size=228
MacBook-Pro-2:~ cmorris$
Thank you for providing the codesign output. Based on the information you’ve shared, the kext is signed properly with a valid Developer ID Application certificate from Bdrive Inc. (Authority chain: Bdrive Inc. → Developer ID Certification Authority → Apple Root CA), and it was successfully notarized (Timestamp: Sep 25, 2025).
It is strange that the kext is not loading due to a signing problem when the code signature appears valid from the codesign output. The discrepancy between the valid signature and the “Bad code signature” error from kmutil is puzzling.
Further investigation will be required to determine why macOS is rejecting the kext despite the valid signature. This may be related to how macOS 26 (Tahoe) handles kext validation differently from previous versions, or there might be additional security requirements we need to address.
We appreciate your patience as we work to resolve this issue.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.