We have one Mac (a MacBook Pro Unibody) amongst our Windows machines which connects to the "server" (actually a Dell running Windows XP Pro) to access documents. This works just fine most of the time, but sometimes after waking from sleep, it cannot connect to any Windows computer on the network.

There are no errors (nor even any messages) in the Console application when attempting to connect either by the Finder's network browsing, nor when using the "Connect To Server" menu, either by name or IP.

I have tried "Relaunch" on Finder, toggled File Sharing, disabled and re-enabled the Airport, but nothing makes the Mac able to connect again until I reboot it!

Other computers can connect to the machines, so it is definitely the Mac at fault.

Are there any workarounds that anyone has found? Is there perhaps a way to re-start the samba client?


The laptop is indeed using wireless, but all network connectivity is working, the Mac can ping the XP host it's trying to connect to and browse the internet just fine. I've tried using the IP address of the host machine in the "Connect to Server" menu item; That is now mentioned above.

  • I'm curious to know how this is going for you. Any progress? – Spiff Mar 26 '10 at 23:53

[Edit: Removed questions you answered in your edit, asked new questions, made clarifications.]

  1. Does the mounted SMB share (or a folder with the same name) still show up in /Volumes ?
  2. What does the mount command report?
  3. Does umount /Volumes/<name of share> do anything? (Note that it's "umount", not "unmount").

Note that Mac OS X's Console log generally only reports messages from apps that run as the current user. Software that runs as root (or "nobody" or any of the default restricted system accounts like "www") generally logs to /var/log/system.log or other logs. In 10.6, kernel messages, which most likely include filesystem messages, go to /var/log/kernel.log, so look there too. The Console app lets you browse all these logs if you hit "Show Log List". Mac OS X's SMB client (which I seem to recall is Apple's own implementation, not Samba-based derives from Boris Popov's FreeBSD smbfs, which is not Samba-based) probably doesn't run as the current user, so it probably doesn't log to the console log. Look in the system.log and the kernel.log.

  • I'm pretty sure that samba (client, at least) is installed, but perhaps Finder uses its own thing. I'll definitely have a look in the system.log when this happens again, thanks for that info. – Drarok Mar 18 '10 at 11:10

I strongly recommend you check the TCP ACK fix here. I have applied it in many situations where Mac OS X clients choke in Windows environments & it works great. Detailed explanation here.

The short version, of what this does: There is a mismatch error in the way the Mac OS X TCP stack handles TCP ACKs which basically results in packet loss. Spinning beachball? Slow connections? Stuff like that. A fix like this does not risk corrupting data because it is changing the way TCP packets sent/received behave. So instead of using a flawed implementation of Nagle’s algorithm, the setting disables the algorithm so packets can just be sent/received without waiting

Now to start, check this from the terminal:

sysctl net.inet.tcp.delayed_ack

It should be one of 4 numbers:

  • 0 = Responds after every packet (OFF)
  • 1 = Always employs delayed ACK, 6 packets can get 1 ACK
  • 2 = Immediate ACK after 2nd packet, 2 packets per ACK (Compatibility Mode)
  • 3 = Should auto detect when to employ delayed ack, 4 packets per ack. (DEFAULT)

99% of the time a Mac will be set to option 3, which is what is choking Macs when connected to non-Mac servers. The two options to try are 0 & 2. I default to using 0 nowadays & have not had any issues.

This will set the delayed_ack setting to 0:

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

Unmount fileshares & reconnect. Things should be better.

Now if you want to retain that setting on reboot, you need to create a sysctl.conf:

sudo nano /etc/sysctl.conf

And paste this lone line into it:


If you want to test if you did this right, just reboot your machine & do that sysctl net.inet.tcp.delayed_ack again. It should be 0.

Hope this helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.