Troubleshooting and Fixing macOS Finder Hangs When Accessing Windows SMB Shares


4 views

Many macOS users experience this frustrating scenario: After successfully mounting and accessing Windows SMB shares for some time, Finder suddenly becomes unresponsive when trying to access the shares. The shares appear to remain mounted in Terminal (mount command shows them), but any attempt to interact with them (even via ls or umount) causes the system to hang.

This behavior typically stems from several potential issues in the SMB/CIFS implementation:

  • SMB protocol version mismatches between macOS and Windows
  • Improper handling of TCP keepalive packets
  • Resource exhaustion in the networking stack
  • Caching issues in Finder's network browsing implementation

Before applying fixes, verify the current connections:

# Check active SMB connections
smbutil statshares -a

# View mounted shares
mount | grep smbfs

# Check for network errors
netstat -an | grep 445
dmesg | grep smb

Solution 1: Adjust SMB Protocol Version

Edit /etc/nsmb.conf (create if it doesn't exist):

[default]
# Force SMB2 or SMB3 protocol
smb_neg=smb2_only
# Alternative for newer macOS versions:
# smb_neg=smb3_only

# Keep connections alive
keepalive_time=60

Solution 2: Modify Mount Options

When mounting shares manually or via automount, add these parameters:

mount_smbfs -o noserverino,nobrowse,soft,rdwr,tcp,keepalive \\\\server\\share /mount/point

Solution 3: TCP Keepalive Settings

Add these settings to /etc/sysctl.conf:

net.inet.tcp.keepidle=30000
net.inet.tcp.keepintvl=30000
net.inet.tcp.keepcnt=8

Then apply with sudo sysctl -w.

Solution 4: Force Unmount When Stuck

Instead of rebooting, try this sequence:

# First attempt graceful unmount
sudo umount -f /Volumes/share_name

# If that fails, detach the filesystem
sudo diskutil unmount force /Volumes/share_name

# As last resort, kill related processes
sudo lsof +D /Volumes/share_name | awk '{print $2}' | xargs sudo kill -9

Create a cron job to check and reconnect shares:

#!/bin/bash

SHARE_PATH="/Volumes/data"
SERVER="windows_server"

if ! ls "$SHARE_PATH" >/dev/null 2>&1; then
    # Share is unresponsive
    diskutil unmount force "$SHARE_PATH"
    sleep 2
    open "smb://$SERVER/data"
fi
  • Update to the latest macOS version that supports newer SMB implementations
  • Ensure Windows computers have SMB1 disabled (security risk)
  • Consider using third-party SMB clients like Mountain Duck for critical operations
  • For development environments, prefer NFS or SSHFS when possible

When macOS 10.6.7 clients establish SMB connections with Windows 7 shares (both x86 and x64), they initially function correctly but eventually become unresponsive. Finder displays a perpetual "Connecting..." state while Terminal reveals mounted but inaccessible volumes. Attempts to interact with these shares through commands like:

ls /Volumes/data
sudo umount -f /Volumes/data

result in terminal hangs that resist even SIGINT (Ctrl+C) termination.

Several factors contribute to this behavior in the legacy SMB implementation of Snow Leopard:

  • TCP keepalive packet mismatches between Windows 7 and OSX
  • Resource fork (.DS_Store) synchronization failures
  • Incompatible SMB1 protocol negotiation

Before resorting to a full restart, try these escalation steps:

# First attempt clean unmount
sudo diskutil unmount force /Volumes/data

# If that fails, kill the filesystem process
sudo killall -9 netbiosd

# For stubborn cases, disconnect the TCP session
sudo lsof -i | grep microsoft
sudo kill -9 [PID]

Modify the macOS connection behavior with these configuration changes:

# Set more aggressive TCP keepalives
sudo sysctl -w net.inet.tcp.keepidle=30000
sudo sysctl -w net.inet.tcp.keepintvl=30000

# Disable resource forks on network volumes
defaults write com.apple.desktopservices DSDontWriteNetworkStores true

# Mount with explicit SMB protocol version
mount_smbfs -o nobrowse,soft,prot=smb1 //user@server/share /mountpoint

When native SMB proves unreliable, consider these alternatives:

# Use NFS instead (requires Windows Services for UNIX)
mount -t nfs server:/share /mountpoint

# Or SSHFS for encrypted transport
sshfs user@server:/share /mountpoint -o reconnect,volname=RemoteShare

Implement these commands to monitor connection health:

# Continuous SMB status monitoring
sudo fs_usage -w -f filesys smb

# Packet capture for protocol analysis
sudo tcpdump -i en0 -s 0 -w smb.pcap port 445