Apple - Mac mini can't connect to my corporate SMB server. Was working some days ago
SUCCESS!!
After 2 months of (moderate) misery I've finally found the reason SMB didn't work with my Sierra Mac Mini.
TL;DR The reason was this installed kext:
com.intel.kext.intelhaxm (6.0.1) 8FF2C637-0A5E-367E-B007-5B08655B1E8A <7 5 4 3 1>
You can check if you have it installed with the following command from an ordinary Terminal:
kextstat | grep -iv apple
In case you have it (and in case you're also suffering SMB connectivity problems) you can uninstall it typing the following command, again, from an ordinary Terminal (no need to boot in Single-User mode):
sudo /Library/Extensions/intelhaxm.kext/Contents/Resources/uninstall.sh
Follow the on-screen instructions, REBOOT, and you're done :)
Doing that you'll lose hardware acceleration inside your Android emulators, but they will work in software-rendering mode. Not brilliant, but it's something. You can reinstall HAXM in case you really need Hardware Acceleration for Android emulators again (but be prepared to lose SMB connectivity again (?)).
Long answer:
If you use your Sierra Mac to develop Android stuff you'll probably have installed the typical random needed modules (Android SDK's, emulators, drivers, etc...) The thing is, "Intel HAXM accelerator" is one of the typical drivers you install if you want proper hardware acceleration of your emulators for Android developing. Well, apparently, and believe it or not, that driver is not compatible with using SMB under macOS Sierra, at least with my MAC.
Sierra SMB subsystem and HAXM are apparently unrelated pieces of software, but it seems they are somehow incompatible between them. In case you have SMB problems you'll have to decide which of the two you really need more:
SMB or proper fast emulators for Android development.
I chose SMB :)
Thanks EVERYONE in this question, answering, commenting, etc... specially Brett who, after many weeks, put me after the correct lead.
I had the same problem (1025 failures to open smb device, syserr = No such file or directory) and finally tracked it down to the /dev/nsmb0 device not being correctly configured because of a conflicting kext from a very old 3rd party app. If you cat /dev/nsmb0 and get "Device not configured", it's possibly a similar issue.
To solve it, I looked at all the non-Apple kexts and removed apps / kexts one at a time until it worked. I had to boot into single user mode (cmd + s during boot) to remove some of them.
You can search through your loaded non-Apple kexts using kextstat | grep -iv apple. Here's an example of the output for me on a working system:
Index Refs Address Size Wired Name (Version) UUID <Linked Against>
82 0 0xffffff7f8284c000 0x7000 0x7000 net.sf.tuntaposx.tap (1.0) 23FDB715-3D0D-3A26-ACBA-E3794C231CB7 <7 5 4 1>
83 0 0xffffff7f82853000 0x7000 0x7000 net.sf.tuntaposx.tun (1.0) 95DD963D-E23D-3B0F-8DE8-A4D2F6BFA5CC <7 5 4 1>
87 3 0xffffff7f8287c000 0x63000 0x63000 org.virtualbox.kext.VBoxDrv (5.0.28) 4ED2DD49-255E-37C8-A0B8-2556670B17B1 <7 5 4 3 1>
144 0 0xffffff7f8363e000 0x7000 0x7000 com.zerotier.tap (1.0) 8BA59C0A-B3A7-3418-BFF5-B4914CE7734A <7 5 4 1>
146 0 0xffffff7f83645000 0x8000 0x8000 org.virtualbox.kext.VBoxUSB (5.0.28) E7605ACF-20E3-3016-94E2-A6013CD9260F <145 87 40 7 5 4 3 1>
151 0 0xffffff7f8366f000 0x5000 0x5000 org.virtualbox.kext.VBoxNetFlt (5.0.28) 89C23056-9027-33DB-852A-429BFA00D6DE <87 7 5 4 3 1>
152 0 0xffffff7f83674000 0x6000 0x6000 org.virtualbox.kext.VBoxNetAdp (5.0.28) 1A767D65-6674-3A9F-B305-DAA197F109CC <87 5 4 1>
You can unload kexts by filename with:
kextunload /System/Library/Extensions/KextName.kext
or for the bundle name:
kextunload -b com.example.kext.name