Resolved smbfs - konstant kernel panic > caused by SMBv1 on Windows (probably)

[arw]

Update #Resolved:
The original title was "prevent/block system extension from loading (smbfs causes konstant kernel panic)".
I think I found what differs in my setup from most other users and leads to the problems with smbfs.
I therefore changed the title accordingly.
-> Post #8

tl;dr: A windows 10 machine in my network has SMBv1 enabled via the "SMB 1.0/CIFS-Server" feature.
This seems to trigger "com.apple.filesystems.smbfs" on all of my Macs and sooner or later causes kernel panics.
Happening since the first release of macOS Big Sur.
______________________________________________

Hello,
on a normal Big Sur install (non Open Core), is there a way to prevent a specific kernel extension from being loaded?
In my case, "filesystems.smbfs" causes constant kernel panics when a Thunderbolt device is connected.
I don't use SMB but as soon as I connect my machines to a network (WiFi, ethernet) the "com.apple.filesystems.smbfs" from "/System/Library/Extensions/smbfs.kext" gets automatically loaded for an unknown reason.
With disconnected network and therefore no loaded "smbfs", there are no problems whatsoever.

The cause must be in my network as I get the SMB caused kernel panic on every device (fresh install) since the first release of Big Sur. I can't change that but simply preventing the "smbfs.kext" from being loaded would solve my issue.

Thank you.

Spoiler: kernel panic log

Kernel Extensions in backtrace:
com.apple.iokit.IOSCSIArchitectureModelFamily(436.140.1)[D547C219-43FC-3D78-AB6E-99CFEBAE4FE6]@0xffffff80093a9000->0xffffff80093bcfff
com.apple.iokit.IOSCSIBlockCommandsDevice(436.140.1)[1BAAFD24-BDAD-3A98-A637-3FDAE19BCE8C]@0xffffff80093ce000->0xffffff80093dbfff
dependency: com.apple.iokit.IOSCSIArchitectureModelFamily(436.140.1)[D547C219-43FC-3D78-AB6E-99CFEBAE4FE6]@0xffffff80093a9000->0xffffff80093bcfff
dependency: com.apple.iokit.IOStorageFamily(2.1)[C5C617C0-1DA6-36CC-9C1A-775E9A08FB51]@0xffffff8009470000->0xffffff8009481fff

Process name corresponding to current thread: kernel_task

Mac OS version:
20G1231

Kernel version:
Darwin Kernel Version 20.6.0: Thu Mar 9 20:39:26 PST 2023; root:xnu-7195.141.49.700.6~1/RELEASE_X86_64
Kernel UUID: 16F174F8-4EC4-30AA-94B2-6FD0FC398C34
KernelCache slide: 0x0000000006600000
KernelCache base: 0xffffff8006800000
Kernel slide: 0x0000000006610000
Kernel text base: 0xffffff8006810000
__HIB text base: 0xffffff8006700000
System model name: MacBookPro16,1 (Mac-E1008331FDC96864)
System shutdown begun: NO
Hibernation exit count: 0

System uptime in nanoseconds: 644163534561
Last Sleep: absolute base_tsc base_nano
Uptime : 0x00000095fb23843a
Sleep : 0x0000000000000000 0x0000000000000000 0x0000000000000000
Wake : 0x0000000000000000 0x0000000612361bae 0x0000000000000000
last started kext at 524068006487: @filesystems.smbfs 3.6.2 (addr 0xffffff7fa214a000, size 491520)
last stopped kext at 626505548565: @filesystems.smbfs 3.6.2 (addr 0xffffff7fa214a000, size 491520)
loaded kexts:

edit: I know I'm leaving out some information (exact workflow) but for now I hope there is a simple answer to my question. I am in the process of updating all of our Macs but for that I need to back them all up which is a pita with said problem.
All Macs suffer the same SMB kernel panic problem: 2x Mac Pro 2013, MacBook Pro 2020 Intel 13" , MacBook Pro 2019 16". Big Sur 11.7.6.

 

[chrfr]

Before trying to figure out how to remove an extension I'd start by updating to the most recent version of Big Sur, if not a newer, still supported version of macOS.
The fact that the smbfs extension is the last to load doesn't necessarily indicate that's the source of your problem. The extensions in the backtrace are more relevant, and they point to an external USB drive as being the cause of the panic. I'd check for corruption on that disk, check for firmware updates, but also update to 11.7.10 which is the last version of Big Sur if you can't go to something newer.

 

[arw]

Thanks for your suggestion.
But that's my predicament, I do want to update but backup/sync all Macs and users before doing so, which fails.

I do not have corrupted disks as I always format and restore from a clean backup.
I tried different USB drives.
My routine involves Target Disk mode via Thunderbolt, hence the backtrace.

If I disconnect the Mac from my network, smbfs isn't loaded and no problems occur.
It just makes everything a lot more difficult but that's how I will move forward for now.

I just don't have the time/nerve for deviating from my normal routine and was hoping for a temporary fix.

 

[chrfr]

Thanks for your suggestion.
But that's my predicament, I do want to update but backup/sync all Macs before doing so, which fails.

I do not have corrupted disks as I always format and restore from a clean backup.
I tried different USB drives.
My routine involves Target Disk mode via Thunderbolt, hence the backtrace.

If I disconnect the Mac from my network, smbfs isn't loaded and no problems occur.
It just makes everything a lot more difficult but that's how I will move forward for now.

If that’s the case, connect the external disk, run a Time Machine backup, then disconnect the external and connect the computer to the network and upgrade.

 

[Bigwaff]

The cause must be in my network as I get the SMB caused kernel panic on every device (fresh install) since the first release of Big Sur

Do you have File Sharing turned on?

 

[arw]

Thanks again.

Before an update, I sync the most recent version of each user account into one main machine so I have a single "master" backup for all six machines. Using Carbon Copy Cloner.

While I had to prepare all images on USB drives, the backup/sync finished just now as expected with no kernel panic -
The crucial element was to disconnect the network and ensuring the "smbfs.kext" wasn't loaded before initiating the Thunderbolt connection.

I also do not have high hopes as this issue persists since the first version of Big Sur and iirc also in Monterey. Also with a fresh install.
While there must be some specific variable in my network, switching from mounting SMB network shares to AFP previously prevented the "smbfs.kext" from being loaded.

If do not know what changed, as all Macs now load the "smbfs.kext" shortly after a network connection is established.

Do you have File Sharing turned on?

No. No File Sharing enabled on the Mac side. They all only access AFP shares.

 

[chrfr]

Thanks again.

Before an update, I sync the most recent version of each user account into one main machine so I have a single "master" backup for all six machines. Using Carbon Copy Cloner.

While I had to prepare all images on USB drives, the backup/sync finished just now as expected with no kernel panic -
The crucial element was to disconnect the network and ensuring the "smbfs.kext" wasn't loaded before initiating the Thunderbolt connection.

This problem is certainly something specific to your network, given that it affects all your computers but isn't a widespread problem in general. How exactly are you connecting to this "one main machine" and exactly what devices are you using over thunderbolt and USB? When the network is connected, are you sharing a volume from another computer or device to these computers?

 

[arw]

                                                                            /-----------\
  _____________                                                            |   Mac Pro   |
 |             |                                                           |    2013     |
 | MacBook Pro |                                                           |     in      |
 |             |           Apple                          Apple            | Target Disk |
 |_____________|   < Thunderbolt 3 to 2 Adapter > < Thunderbolt 2 cable >  |     Mode    |
/_______________\                                                           \___________/

On the MacBook, no network shares are mounted and sharing is disabled.
Simply connecting to my network via WiFi or ethernet is enough to trigger starting "smbfs" and soon results in a crash of the MacBook.

But I think I finally found the culprit:
To import weekly pdf newspapers into iBooks on my 1st gen iPads from a network share, I had to enable the "SMB 1.0/CIFS-Server" functionality on my Windows 10 server (years ago).
That results in an additional Windows service running named "Computerbrowser" that links to the "Server" service.
Stopping "Computerbrowser" or disabling the feature completely, stops triggering the Macs to load the "smbfs" extension.

Even without any peripherals connected, every one of my Big Sur machines soon crashes when SMB shares are mounted. That's why I fully switched to AFP.
I am cautiously optimistic that the "SMBv1" part is the root of all evil in my setup and simply incompatible with macOS Big Sur and above.

I will do some more testing and if successful, edit the first post and thread title.

Thanks so much for your questions that made me re-evaluate every component involved!

 

[chrfr]

Even without any peripherals connected, every one of my Big Sur machines soon crashes when SMB shares are mounted. That's why I fully switched to AFP.

So just to clarify, the panic doesn't happen when the Macs are connected to your wifi/ethernet network, the panic happens when one of those computers connects to your Windows 10 computer. Is that correct?

 

[arw]

Almost.
Mounting and working on an SMB share of said PC soon resulted in a panic.
In normal operation, connecting to a non-SMB share of the same computer is fine (AFP).

The exception is the illustrated constellation from above with a connected Thundebolt Mac in Target Disk mode. There the MacBook panicked by simply being in the same network as an SMBv1 enabled Windows machine. No network shares mounted at all.
Since I disabled the SMBv1 feature earlier, no problems on the Mac side anymore. And "smbfs" is not being loaded.

If it stays that way, I will then try mounting SMB shares again.

It would finally make sense that I found so little about this issue in the past. Having manually enabled SMBv1 is quite the exception.