16

I used to access my local Windows 2008 file server's SMB shares on my recent (3 weeks old) MacBook Pro without problems. However, for a few days now, it fails to (re-)connect to the server after it woke up from sleep mode.

Finder just shows "connecting..." and hangs indefinitely. The same thing happens when I try it from the command line (mount -t smbfs). This happens via both WiFi and cable, I also tried turning networking off and back on. The only thing that helps is a reboot.

Any hints?

Edit to clarify: It's the Mac that's being put to sleep, not the server. I also found out that if I disconnect the shares before I put it to sleep, it will be able to reconnect after waking up.

Another Edit:

I did some more investigation and sniffed the network traffic. The Mac sends NetBIOS name queries and a status request (NBSTAT) to the server, the server responds, everything seems fine. After that, the Mac should open a SMB connection, but it doesn't do anything. No more packets follow.

I then found out that the real problem lies deeper. It seems it doesn't open a new connection because it thinks the old one, which has of course timed out on the server side, is still active. However, any program that tries to access its mount point or just the /Volumes directory hangs and can't even be killed. umount /Volumes/share - hangs. ls /Volumes - hangs. kill -9 any of these - doesn't help. Also, opening a file open dialog in any application causes it to hang as well!

The only thing that helps is a hard reboot. It seems to me there's something fundamentally wrong in OSX's SMB implementation if a timed out connection can trigger something like this.

0

3 Answers 3

6

I'm having the same issue with my MacBook Pro. I followed the instructions here - http://blog.djmnet.org/2009/02/09/macs-needing-unix-network-geekery/ and my issues seem to be resolved.

2
  • 1
    Wow, thanks! That seems to have done it. I disabled darwin_streams in smb.conf and added this to my sysctl.conf: net.inet.tcp.delayed_ack=0 net.inet.tcp.mssdflt=1440 kern.ipc.maxsockbuf=500000 net.inet.tcp.sendspace=250000 net.inet.tcp.recvspace=250000 After a reboot, I connected to my SMB shares (which already took a lot less time than it used to) and after a few sleeps later, I can still access them perfectly.
    – Andreas
    Apr 15, 2011 at 10:04
  • Actually, I still ran into the problems after applying these changes. However, OSX Lion seems to have fixed the issue.
    – Andreas
    Mar 15, 2012 at 14:52
4

Hey, I recently had the same problem with my 2010 MBP, I found the solution to be a combination of two things.

The first is a kernel tweak ( essentially TCP_NODELAY on the connections ), which can be done in Terminal:

sudo sysctl -w net.inet.tcp.delayed_ack=0

Second, is dealing with file permissions / DS_Store files. Commonly when you setup Windows shares the Mac will only have read access. Finder tries to create them in every folder you view and can eventually hang. So there are two options to solve this - enable sufficient file permissions on the Windows machine, or stop Finder from creating these files on network shares. I prefer to disable finder from creating them, which can be done by running the following command in terminal:

defaults write com.Apple.desktopservices DSDontWriteNetworkStores true

You'll need to reboot after running them.

1
  • On my Mac OS 10.7.2 system the default value (should you need to restore it) is "net.inet.tcp.delayed_ack: 3" (you can get the default value by running "sudo sysctl -a").
    – Per Noalt
    Dec 6, 2011 at 20:57
2

I can't help solve the problem, but I can add a little bit more detail. It also happens on Windows 7 and the OS X device must still be connected when the windows share is put to sleep. If you disconnect or sleep OS X, and then standby Windows you do not experience this problem.

I would really like a solution to this as well.

Edit: After some searching many other people have had similar problems:

You must log in to answer this question.

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