Mac mini can't connect to my corporate SMB server. Was working some days ago

Question

I'm at work, and my Mac mini has stopped being able to connect to the corporate SMB server shared folders.

If I try Finder > Connect to Server (using the URL stored there from previous successful connections), macOS Sierra complains with a more than useless "generic error".

In my Console logs I can't detect any error related with samba (where should I be looking into?)

There are clonic Mac mini machines on the same floor (my coworkers' ones) and they can connect to this server without any problem.

If I ping this machine from my command line, I can see it perfectly.

If I try this on the command line:

smbutil view smb://192.168.XXX.XXX/docs/

macOS Sierra yields this:

smbutil: server connection failed: No such file or directory

If I try that very exact command line onto a coworker machine, it just lists the shared resources hanging from that SMB server...

Any hint? Maybe it's something related to some service being disabled by mistake in my Mac mini?

I don't have access to my company Samba Server machine and configuration.

I've read and googled many pages around and I'm more than lost.

In case it might be useful, I use MacPorts. It might seem a random thing to add here, but maybe I'm not aware of some library I might have installed that might be known to be troublesome with the official OS X SAMBA client.

Answer 1

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.

Answer 2

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

Answer 3

Are you connected to any other SMB shares at the same time? I today reported a bug to Apple regarding macOS Sierra whereby if I'm connected to another SMB share on a different server, when trying to connect to a second one it will use the original IP address and the share path from the new server.

For example

1. Already connected to smb://192.168.0.2/share1
2. Attempt to connect to smb://192.168.0.3/share2
3. Analysis of packets shows that macOS attempts to connect to smb://192.168.0.2/share2, which doesn't exist.

The only workarounds I've come up with are to either connect to disconnect from the first server before attempting connection on the second. However this does mean that you can only have one SMB connection open at a time.

A slightly better solution was to use the hostname for the server instead of the IP address. This seemed to allow me to connect to the second SMB server without issue. If you don't know the hostname you can get it by opening terminal and typing the following command.

host <ip_address>

Hope this helps.

Edit - I thought it might be worth mentioning that this issue seems to affect all clients that have been upgraded to Sierra.