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.

  • I have no idea if I have a (system software) firewall, and I can't remember having one or having messed with its configuration in the last months. My corporate SMB shared folders just stopped working out of the blue.
    – Isaac
    Oct 19, 2016 at 12:26
  • Disabled (it probably has been in that status since I got this Mac)
    – Isaac
    Oct 19, 2016 at 12:40
  • Same thing. Mi machine shows "No such file or directory". Mi coworkers' Mac shows the full resource list. BTW, both Mac's (my coworker's and mine) are lacking /etc/nsmb.conf file. I've google around, and some people seem to have this file... Not us though.
    – Isaac
    Oct 19, 2016 at 13:08
  • One more to try... use a username of an account you know (coworker, perhaps) is on the SMB server. So, your command should look like this: smbutil view smb://[email protected] (I'm also assuming you can ping this server from your machine, BTW)
    – Allan
    Oct 19, 2016 at 13:17
  • Yes, your directions are clear and easy, but same thing. I've tested it with many coworker usernames and same thing: "No such file or directory". I've tried -G -g and -a parameters, and nope. OTOH: Yes, that SMB server is perfectly pingable from my machine. Also, a proper nmap shows ports 139 and 445 open (IIRC these are the relevant ports for SMB (?))
    – Isaac
    Oct 19, 2016 at 14:13

3 Answers 3



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.

  • 5
    Thank you. After removing haxm I needed to reboot for it to take effect. But I hadn't previously rebooted, after seeing the error, so could have just solved itself. Nov 25, 2016 at 19:02
  • 4
    Thanks a ton for this! I was going crazy after an upgrade from El Capitan to Sierra broke printing. Wish I realized the samba angle before and landed here sooner.
    – Vijay Dev
    Oct 6, 2017 at 20:22
  • 3
    Joining the “thanks” chorus, @Isaac. This had been driving me crazy for 2 hours straight.
    – DomQ
    Aug 25, 2018 at 21:29
  • 3
    Thank you .. exactly my problem apple.stackexchange.com/questions/339412/…
    – boecko
    Oct 13, 2018 at 7:11
  • 1
    I recently installed Android Studio and my network drives would no longer connect. Not through Finder, through terminal, smb/cifs, nothing. This answer was exactly the problem. Cheers to you; I would've never found it. Nov 16, 2018 at 16:47

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
  • It looks REALLY promising. I'm at home right now, but tomorrow I'll try it at work. For some project I need to use tap and tun, and I can see them listed there. I'm more than sure they're interferring with Sierra somehow, so I'll keep you informed
    – Isaac
    Nov 21, 2016 at 21:36
  • 1
    That list of kexts is what's running right now while SMB is working. I just included it as example output. Tap / tun seem to be working fine for me, so I've edited the question to clarify.
    – Brett
    Nov 21, 2016 at 21:58
  • Being at work, it's kind of difficult getting some free time to start messing with my kexts... When you unload a kext, do you have to reset just afterwards? I also have kexts I'd better not uninstall (tun, tap, virutalbox, etc...) Or I have no idea how to properly reinstall them afterwards in case they're not the culprit... In my list I have these different kexts (compared with yours): com.Cycling74.driver.Soundflower (2), org.pqrs.driver.Karabiner (10.21.0), org.pqrs.driver.VirtualHIDManager (1.1.0), com.intel.kext.intelhaxm (6.0.1). The ones I didn't list are included in your working list.
    – Isaac
    Nov 23, 2016 at 8:45
  • I'd try removing Karabiner. The old 3rd party app that was causing me issues was KeyRemap4MacBook, which is now called Karabiner.
    – Brett
    Nov 23, 2016 at 14:17
  • To answer the other questions, if you can remove the kext without being in single user mode, you probably don't need to restart. Karabiner's uninstall didn't work for me, so I had to boot into single user mode and manually delete the kext from /System/Library/Extensions after unloading it.
    – Brett
    Nov 23, 2016 at 14:19

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://
  2. Attempt to connect to smb://
  3. Analysis of packets shows that macOS attempts to connect to smb://, 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.

  • Nope, I can't connect to any SMB share. I think you're describing a different case than mine... Thanks anyway.
    – Isaac
    Nov 21, 2016 at 21:30
  • Ok pal no worries. Do you have admin rights? I read something earlier that said users without root couldn't mount shares to /Volumes since the upgrade to Sierra.
    – ryansin
    Nov 21, 2016 at 21:31
  • Another troubleshooting step you could try is using wireshark to record packets to/from that particular IP address just as you try to connect
    – ryansin
    Nov 21, 2016 at 21:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .