72 Hour Apple Black Friday Sale
Parallels Desktop
Parallels Desktop 9 for Mac Run Windows apps and Mac apps side-by-side, without restarting! Now supports Windows 8 on your Mac. Integrates Mountain Lion and Windows 8 features, such as centralized notifications, and Mission Control and Launchpad for Windows apps. Also runs OS X as a guest OS.

"I found Parallels faster at every common task, like starting and restarting Windows, and resuming Windows from a suspended state."
--Walt Mossberg, New York Times

Snow Leopard and File Sharing Tips and Reports

Issues with Mac OS X 10.6 and SMB and AFP file sharing

Updated January 19, 2012
On This Page:

If you’re using Snow Leopard about any problems or tips.



GoToMyPC - MyPC is on my iPhone.

Mountain Lion Server for Dummies

 

Deals from Amazon

Snow Leopard Server for Dummies

How to support Windows clients on a Mac server, connect your Macs to Active Directory, and more



Snow Leopard Tips and Reports

iPhone and Exchange Server Tips and Reports

Windows Servers and Macs


Windows on Mac

- Virtual PC 7.x
(PowerPC Macs




GoToMeeting - Online Meetings Made Easy

Intro

As with the introduction of Leopard and Tiger before it, Snow Leopard brought reports of new problems with file sharing with Windows servers and clients. Check this page for updates to problems and solutions for cross-platform file sharing with Mac OS X 10.6.

TIPS and Reports

TIP: Snow Leopard Server bug and fix with AFP and Kerberos | Top of Page |

Monday, August 31, 2009

Apple reports a problem with Mac OS X Server 10.6 where AFP users cannot authenticate with Kerberos after the server is upgraded. Apple posed a fix that requires restarting the server:

On the AFP server, execute the following command in Terminal using the correct Kerberos REALM_NAME and a user account authorized to make changes in the Kerberos database:__

sudo sso_util configure -r REALM_NAME -a diradmin -p diradmin_password afp__

Note: The sudo command will prompt for the current user's password. Optionally, you can exclude -p diradmin_password if you want to prompt for the diradmin's password as well.


Problem with Snow Leopard and SMB file sharing -- can't see folders| Top of Page |

Wednesday, September 2, 2009

James Spencer reports that he cannot browse some of his SMB shared folders in Snow Leopard, either in the Finder or the command line:

You're asking for reports of 10.5.8 update breaking SMB shares, but I have a similar problem on Snow Leopard where not all of my folders show up in the Finder or in Terminal. In the Finder, if I use go to folder, I can enter the folder I know is there, but it will most of the time knock me back up a directory. In Terminal I also cannot see the folder, however I can cd to it and copy files from it. I get this error while browsing the SAMBA share: smbfs_smb_lookup: smbfs_smb_qpathinfo error = 16

I've rebooted both systems, removed and created a new share. The problem persists.

If you've seen this problem

TIP: Workaround for syncing SMB folders that don't appear on Mac

Tuesday, April 13, 2011

Two readers commented on the Snow Leopard problem where some shared SMB folders don't appear in the Finder or in Terminal. One reader (name not given) provide a workaround for using the rsync Terminal command for syncing:

I have the same problem described on your site here. I'm using Mac OS X 10.6.7. I want to rsync some documents from a Win 7 x86 PC. Some folders just don't show up and cannot be rsynced. I try to access it with command line, I can cd the lost folders.

The workaround for this problem is installing a RsyncServer on my PC. It works perfectly with my Chinese-character-name subfolders. Though I have to sync the whole folder every time.

If you've tried this

Meanwhile, another reader posted a note in our Forums saying he has a similar problem, but he can see the shares from Windows running in Parallels Desktop on the Mac.

Snow Leopard SMB file sharing issues with Win servers, workstations

Wednesday, September 9, 2009

More readers are reporting that SMB file sharing no longer works after updating to Snow Leopard. Although we received a number of reports, two readers sent some details trying to connect to servers and to Windows workstations. Greg Masada found that the problem only occurs when there is a Windows domain. Otherwise, file sharing works with Windows 2000 and 2003:

I've encountered an SMB file sharing problem using Snow Leopard as well. AsI work in a testing lab I have tried various configurations to try and see

what is affected. Just to be specific about configurations and the exact details of the problem I will list them below.

The problem was first noticed when trying to connect Snow Leopard to an SMB share on a Windows 2000 Server box. The SMB connections work fine under Leopard and Tiger.

  1. Hit Cmd K - Connect to Server window appears
  2. Type "smb://IP_ADDRESS" where IP_ADDRESS is the well, the IP addres of the server
  3. Hit Connect
  4. Enter your name and password for the server appears
  5. Type in authentication credentials (note both domain\user and just user name were tried)
  6. Type in password and hit Connect
  7. Message appears: "You entered an invalid username or password. Please try again."

The same happens when I tried connecting to an AFP share on the same box. There is no WINS server and the credentials are handled by an NT 4 domain controller box. All the Intel Mac machines in the lab have been tried with no success. I have tried most of the stuff mentioned on Apple's Discussion Board and none of the suggestions given have worked.

I went and did some more investigating. I set up a Windows 2003 Server box and tried connecting Snow Leopard to its share. It worked. I set up another Windows 2000 server box and tried connecting and it also worked. Both of these boxes were not set up on the domain and used local authentication. When I added the boxes to the NT domain, voila! Snow Leopard could no longer connect to either box. I have also tried connecting using local authentication again (while still on a domain) and that doesn't work now either. So, adding the box to an NT domain broke connecting to the 2000/2003 boxes whether connecting to a domain account or local account.

I still haven't come up with any reasonable workaround and am looking forward to hearing about any that comes about.

Jeff Emmel encountered file and print sharing problems with a connect Windows XP workstation:

I installed Mac OS X 10.6 last night and lost connection to my Windows XP machine that has the printer and files I need to access. Yikes.

I installed 10.6 on Friday, 09/04/09, one week before 9/11. I immediately lost my email, print and file share.

MacBook Pro w/ 10.6. File and print share are checked in the share window. XP Pro with HP 6L attached. Netgear router and Qwest DSL.

  1. I can talk to the wan/Internet.
  2. I can ping my XP print and file server.
  3. The file server does not show up in Finder.
  4. I get a disconnect error when I Go, Connect to server,
  5. I can not get my MacBook Pro to see it in Finder or any other program to share files or to print.
  6. Mail is intermittently sending. I can't tell if it is intermittent receiving.

I called Apple tech support and they acted like I was from Mars and they have never heard of these problems.

If you've seen these problems

TIP: Workaround for Snow Leopard SMB problems

Friday, September 11, 2009

Two readers independently offered the same fix for problems logging on to SMB file sharing with the first release of Snow Leopard. The fix is to use a path in a specific form of a path in the log-in window:

Andrew Cunningham uses it to connect to a Windows domain:

I have found a solution to connecting to Windows domain machines on our network managed by a Win 2000 Domain controller. Under 10.5, using "Cmd-K" connect to a particular machine , say, "TestMachine" on the domain you could just enter a machines "local" username , say, "andrew", and a password to connect. Now you need to enter "TestMachine\andrew" as the username, and it works for me now.

Alex Hicks uses it to connect to an individual PC:

We were having issues connecting our newly upgraded Snow Leopard Macs to one of our PCs. We could ping the PC and could see it on the network. We found a workaround, on the login, entering SHARD_FOLDER_NAME\USERNAME and PASS we were able to access it.

If you've tried this workaround

Reader confirms Snow Leopard tip for logging into Win share

Thursday, July 7, 2011

Matt Edwards confirmed a tip for logging on to a Windows share with Snow Leopard:

I was having a problem connecting to my Windows Server 2003 share. I tried a lot of stuff, but turned out I just needed the server name before user name. Here is the tip I used. Thanks for the help!

If this is useful to you .

TIP: Reader edits config file (/etc/hosts) to fix Snow Leopard SMB file sharing issue

Friday, September 18, 2009

Hermann Vorster edited a text configuration file in Snow Leopard to fix a problem logging on to Windows SMB file servers:

I've fixed my problem. As far as I can tell, Snow Leopard is fully capable of discovering the network share, but it is having problems resolving the IP address of the server. So, if you edit /etc/hosts and add the IP address and host name of your server, Snow Leopard knows exactly where to find the server and all is solved.

For example: 192.168.1.x hostname

I'm sure there is an easier way to do this with DNS masquerading on one's router, but this is certainly a quick fix.

If you've tried this approach

Meanwhile, Hasan Saydam from Germany verified a workaround for connecting to a Windows workstation from Snow Leopard:

Thanks a lot for your report. Connections to the share as described in the post are working fine. Now I can connect to my share from my MacBook Pro to my Thinkpad and everything is fine.

Reader confirms edit of /etc/hosts to fix Snow Leopard SMB login issue

Monday, January 11, 2010

David S. verified a suggestion of editing the /etc/hosts file on a server to workaround to Snow Leopard problems logging into Windows file servers:

Yes, this works. Annoying, but I don't have a WINS server on the LAN, so it's the way to go.

If you've tried this

Reader verifies "/etc/hosts" fix for Snow Leopard SMB log in problem

Thursday, January 28, 2010

Alessio Dorigo confirmed the suggestion of editing an SMB server's /etc/hosts file to fix Snow Leopard problems logging into the server:

Editing /etc/hosts by adding the IP and name of the server solved the problem -- Thanks!

If you've tried this approach

Tip for Snow Leopard SMB browsing issue: use numeric password

Wednesday, September 23, 2009

Chuck Sumner has a new workaround for Snow Leopard problems with SMB shares. He also said another workaround didn't work:

Changing my samba share password to an all numeric password did solve the problem for me. Editing my /etc/hosts file did not work as far as allowing me to connect to a SMB share via 10.6.1.

If you've tried the password approach

Greg Masada updated his previous report to describe what worked and didn't work for him with password connection problems:

The workaround from Andrew Cunningham works for me:

Machine_Name\Local_Account_Name
Password

I had been using Domain_Name\Domain_Account_Name for NT Domain testing (which still doesn't work under 10.6.1) and for local accounts I had just been doing Local_Account_Name without the machine_Name preceding it. To summarize, this failed:

Local_Account_Name
Password

This worked:

Machine_name\Local_Account_Name
Password

Reader's file sharing issue with 10.5.8 got worse with 10.6

Wednesday, September 30, 2009

Carlos Martins adds to our collection of reports about Snow Leopard file sharing problems, which he has with access Windows shares and network attached storage via SMB (samba):

I started having some issues when I upgraded to 10.5.8 but usually after a reboot it worked fine again; It was kind of random. When I upgrade to 10.6, all was well but last night I lost my Windows shares. Same as some people, can ping Windows, can even VNC to it or remote desktop but no share. I have a NAS with some samba shares and I have the same problem. The first it occurred, I rebooted like I did for 10.5.8 and all was well again until I closed the MacBook lid again and the shares disappeared. When trying to connect to it, it says that the path cannot be found or something similar. I even tried recreating the shares--same result. A reboot won't help anymore.

TIP: Login with port 139 to access SMB shares with Snow Leopard

Thursday, October 8, 2009

Two readers offered another workaround for problems connecting to SMB file sharing in Snow Leopard. Stefan Karos offered this:

In the Connect to Server dialog, type in smb://share:139 .

Where share is the name of the share on your network. I don't know why port 139 has to be specified but once you connect this way, all samba shares appear and can be navigated in the standard network window.

Aaron Maras also reported the same suggestion:

I could not connect to my (Windows SBS 2003 hosted) SMB shares from Finder in 10.6 or 10.6.1 using cmd-k, smb://servername, however using smb://servername:139 works immediately.

If you've tried this suggestion

Snow Leopard "139" SMB server access tip confirmed

Wednesday, October 21, 2009

Two readers confirmed the workaround of using smb://share:139 to log into an SMB server from Snow Leopard, to get around file sharing problems. Jordon Cheung said "Just wanted to say a quick thanks for writing up the below tip. It worked like a charm!"

Serge Rose agreed, "I tried workaround and it works great."

If you've tried this

Another reader confirms the port 139 fix for Snow Leopard file sharing

Monday, October 26, 2009

Brad Carter reports success using the form smb://share:139 to overcome file sharing problems in Snow Leopard:

I have a friend that has two Mac mini's and the one with Snow Leopard quit connecting to his PC. I had him append port 139 to his PC's address in the Connect to Server dialog and it connects. Thanks for the tip on your site.

smb.conf fix for Snow Leopard and NAS also works for Linux Samba server

Monday, December 28, 2009

Dustin Good found that last week's suggestion to fix Snow Leopard problems accessing network attached storage also works accessing an SMB Linux file server. The fix involved adding a line to the device's /etc/smb.conf file. Good reported:

The tip worked for me. Though I was having a problem attaching to a Samba server on an Ubuntu box, the symptoms were identical.

If you've tried this approach

Andrew Rowe, who reported the tip last week, said in his report "Writing files now creates files with proper Windows ACLs instead of just Unix permissions and error code 36 is no longer occurring."

More verification of SL fix, smb.conf edit for Linux SMB server

Thursday, January 14, 2010

Peter Roehl in Hamburg, Germany verified a fix for Snow Leopard problems accessing Linux SMB file servers:

We have the same problems (on 2 Linux Samba Servers) but the Tip from Andrew works for us. Thanks for that. But we have 2 other Linux-Samba-Servers where we can just connect as usual. Even with the same smb.conf file. Strange.

If you've seen this

TIP: Another take on smb.config fix for -36 file sharing error: edit nsmb.conf for "streams=no"

Monday, January 25, 2010

We've previously reported a fix for the Snow Leopard SMB file sharing problem that returns a -36 error when copying files. The fix is to add the line "unix extensions = no" to the /etc/smb.config on the NAS device or Linux server. Several message boards are also reporting that there is a similar edit that can be accomplished on the Mac client. Here's one way to do it:

  1. In the Finder, click the Go menu and select Go to Folder.
  2. Enter /etc/ and click the Go button. The /etc/ folder opens.
  3. Look for a file called nsmb.conf and double click to open it. If it doesn't exist, you'll have to create one.
  4. To create this file, open Terminal and type "sudo vi /etc/nsmb.conf" (without the quotation marks).
  5. Back in the /etc/ folder, double-click nsmb.conf to open it with TextEdit.
  6. Type this in the file:
    #######
    [default]
    streams=no
    #######
  7. Save and Quit.

You may have to restart the Mac.

If you've tried this

TIP: Linux SMB fix for -36 error works for OS X Server; and fix for 2 GB file copy limit

Thursday, January 28, 2010

Rob Francis verified a fix for Snow Leopard client -36 errors with Linux SMB servers. He found that it works with Mac OS X Server. He also had a Snow Leopard Server fix for copying large files over 2 GB:

As it turns out, "unix extensions = no" is all I needed to add to the smb.conf global settings on Snow Leopard Server 10.6.2, Xserve.

Also, unchecking oplock and strict file locking for the SMB share seems to be the key to unlocking large file copying in the other direction and is also recommended in the Snow Leopard Server manual if you more than just SMB enabled on the share. I've seen a lot of posts on different forums about the 2 GB limit and this seems to be the fix.

If you've tried this on Mac OS X Server

Reader confirms smb.conf edit fix for -36 SMB errors

Wednesday, February 3, 2010

Dave Hetherington confirmed a tip last week to fix the problem of Snow Leopard -36 errors. The suggetion is to add "unix extensions = no" to the smb.conf file (or settings) on a Linux server or Mac OS X Server. Hetherington said "We have previously done this on our machines and it works!"

We've also recently posted a variation of this, which is to add "streams-no" to the nsmb.conf file on Snow Leopard clients.

TIP for Snow Leopard issues with SMB: keywords, WINS, & case sensitive Samba

Monday, May 3, 2010

David Lippa sent some solutions for fixing Mac OS X problems with SMB (Samba) file sharing, with Linux and Windows servers. He recommends a keyword, keeping a single WINS server in a subnet, and configure a Samba server for case sensitivity. Lippa's report:

I have some fixes to some of the Snow Leopard problems with Samba.

1) Use the "hide files" keyword instead of "veto files." The Man page says that they won't show up in Explorer (speed things up) but if you know what you're looking for (that's you, Finder!) you can access them.

2) WINS server issues. There can only be one WINS server *per subnet*......
Read entire story here

TIP: Use QuickLook to watch movies over SMB to avoid -36 error

Tuesday, June 29, 2010

Tim McEwan kept getting the -36 error when watching movies located on a network attached storage (NAS) device over SMB. A previously suggested workaround didn't work for him. McEwan's workarounds are to use QuickLook to view the video, or launch QuickTime and access from the Open menu:

I'd just like to add to the slew of reports on error code - 36 and SMB. I have the issue trying to watch videos from my Vantec NAS via SMB. Running the file from Finder results in a 36 error.

My tests/observations:

  • Changes to /etc/smb.conf and a logout/login don't seem to make any difference (I'm not patient enough to wait for a reboot);
  • The issue only occurs for me when running the file directly from Finder, hence the workarounds are:
  • Use QuickLook. I know, just hit spacebar and the file plays - pfft!
  • Open QuickTime first, then browse for the file using the Open menu.

I've only just set my Vantec back up as a NAS (was using via USB for months), so I can't say if this behavior is the same on any older builds. I have two machines here with 10.6.4, and both behave exactly the same.

If you've tried this


Snow Leopard printing issues with Windows shared printers | Top of Page |

Friday, September 18, 2009

Howard McCollum is another reader who can't connect to a Windows printer from Snow Leopard:

I have a new Mac Pro with snow leopard and cannot connect to my Windows XP machine shared printer.

If you've seen this

More on Snow Leopard not printing to Windows printers

Monday, September 21, 2009

Ray Mylchreest's Mac OS X 10.6 installation is not having problems with Windows file sharing, but has the problem of not printing to a Windows printer:

I'm having the same problem. Just got a new MacBook Pro and can see all the shared folders on my Windows Vista Home Desktop. Unfortunately I cannot connect to the shared printer (Epson C62), it just does not show up! When adding a printer using system preferences when clicking the windows tab all three boxes are shaded out. I've followed the advice from other forums and tried through the advanced option. Even with the correct network address Snow Leopard just will not see the printer.

Andy Jackson printing problem is not with a Windows printer, but we thought it might be worth reporting.

So far the only problem I have had while booted into Snow Leopard's 64-bit mode is some weird behavior from my Brother all-in-one. When I tried to print some checks in Quicken 2007 (Rosetta), it failed to print everything on the check, only some of what it should. If I use a blank sheet of paper or turn the checks over and print on the back, everything prints as it should. My Konica Minolta works OK, but it has always had a small alignment problem, even pre-Leopard.

If you've had problems printing to Windows printers from Snow Leopard

More Snow Leopard problems printing to Win shared printers

Wednesday, September 30, 2009

A number of readers have confirmed previous reports of Snow Leopard not printing to shared printers connected to Windows PCs. The problem occurs with Windows servers and workstations, where printing works with older versions of Mac OS X. Some users see it as an authentication problem. Patrick Marquetecken sees this with Windows XP:

I have Snow Leopard but it seems impossible to print to an SMB printer connected on a Windows XP machine, I can select the printer but the print job disappears. The file sharing is working without any problems. A machine with Tiger can print without any problems.

Gary Smith sees it with network printer attached to Window Server:

I recently installed the newest version of MAC OS X Snow Leopard on my macbook pro. I then installed the Parallels Desktop upgrade to 4.0 and now I cannot print from the Parallels platform. I am not sure if it is associated with the Mac security update 2009-001 or not, but my print jobs are not even getting to the print queue on the mac side. The job will show up in the print queue on the Parallels desktop, but not in the print queue on the Mac operating system.

Brian W. has the problem printing to a Windows 7 workstation:

I have not been able to find my Epson 9400 printer on my new MacBook Pro. It is hooked up to my Windows 7 64-bit machine, I can see the shared folders just not the printer.

Nicolas Keller sees an authentication problem with a Windows 7 printer

Snow Leopard printing to Windows 7, I can't get it to work. The printer use to work with Leopard. It Printer can't seem to authenticate. It is an HP OfficeJet 6200. I believe that the problem is more at the OS level than at the printer level. Running Snow Leopard on the Mac and Window 7 RTM on the desktop.

Becky also seems to have an authentication issue with Windows XP:

Though I set up a wireless printing thing between my MacBook and my mom's PC running XP, connected to an HP LaserJet 4 by a serial cable, and it worked fine in Tiger, and even for a day in Snow Leopard, now when I try to print it asks for a user name and password, and nothing I can come up with works. I never set any passwords myself, and neither did my mom on her own end, so we can't figure out where this is coming from. Obviously, I tried both my shorthand admin name "iroha" and my real name "becky.reid" with my administrator password and neither of those works; logging in as a guest does not either. I get "errdos: errbadaccess" errors instead.

I read somewhere online about editing the server configuration file in CUPS, but I have no idea how to do this or work with CUPS or Unix whatsoever. The guy on the phone I talked with at Apple Tech Support gave up on this after about 45 minutes, saying that because I was trying to access the printer through a Windows computer, he couldn't give me any more help. He kept suggesting I connect the printer directly to the Macbook, even though I told him several times that I can't because my MacBook doesn't have a serial port, and my mom needs the printer more than I do.

Michael Hallett:

I recently upgraded to OS X 10.6 from 10.5 and can no longer access a Windows network shared HP printer, which was formally accessible. I can see directories and files just fine, but have no ability to print.

Michael Hausman:

I'm experiencing a similar problem with the Okidata C5500n laser printer. The driver has been disabled by the new code in OS 10.6. It works in Leopard 10.5.8 using the Coco code.

If you know of a workaround

TIP: Fix for Snow Leopard printing issues with Windows shared printers

Thursday, October 8, 2009

Tony Williams offered some suggestions for Snow Leopard problems printing to Windows printers:

A couple of things to look at around solving this problem:

  • Check to see that /etc/cups/printers.conf doesn't have a line "AuthInfoRequired username,password" - if it does remove it and retry.
  • Switching from SMB to LPD can help if the print server supports it.

Make sure you have Kerberos working perfectly and are signing on to the Mac with an Active Directory account.

Reader fixes 10.6 problem printing to Win shared printer

Monday, October 12, 2009

Pat Crail fixed his Snow Leopard probem printing to a Windows-connected printer:

I had the same issue others have reported: new MacBook Pro with Snow Leopard (fully updated), but could not print to a shared printer on a Windows machine via the network. I was able to find and add the printer on the Mac, and the printer model was listed in the drivers setup box, but it wouldn't print.

To resolve the printing issue, I reset the printer setup, then added the printer again. This time, I chose a Canon MP520 Guttenprint driver rather than the Canon MP520 series driver, and used the login and password information that I use to login to my user account on the Windows machine. I don't know if it was the driver or using the incorrect password, but printing works fine now.

TIP: Another fix for Snow Leopard issues with Windows shared printers

Monday, December 21, 2009

Michael Bentley used Terminal to edit his Mac's printer.conf file to fix Snow Leopard problems accessing Windows printers. Previously, we reported a suggestion to remove AuthInfoRequired from the printer.conf file. Bentley took a different approach, changing the line "LPD://[IP Address of Windows Box]" to "smb://username:password@[ip address of windows box]/[Printer Share Name]." Bently said:

I ran into this today and was able to fix it with a bit of hacking printer.conf in /etc/cups/. I blogged the fix here.

If you've tried this fix

Reader verifies printer.conf fix for Snow Leopard shared printer problems

Monday, February 8, 2010

Rich Vuduc verified a previously reported fix for Snow Leopard problems accessing Windows printers. This fix edits the printer.conf in /etc/cups/. Vuduc said:

Regarding Michael Bentley's tip, Another fix for Snow Leopard issues with Windows shared printers, just letting you know that the tip worked like a charm!

If you've tried this workaround

TIP: more fixes for Snow Leopard printing to Windows shared printers

Monday, December 5, 2011

Hussain shared us several fixes for problems with Mac OS X 10.6 printing to printers shared with Windows, including a tip we previously published:

I had the problem of not being able to print to a Windows printer from a MacBook Pro OS X 10.6.8. I have an Epson Stylus NX 125 printer set up as a shared printer on Win XP Pro SP3. These sites helped in getting it to work:

Also did notice that when I went to System Preferences -> Printer & Fax, choose my printer Epson NX 125 and try to print a test page it failed. I could not also open the printer utility or view the ink supply levels either, so I figured it wasn't working. Boy was I wrong, cause as I discovered that if I printed a document it prints! So basically the Mac Printer front ends seems to be broken!!

I would suggest going to 127.0.0.1:631 and use the CUPS interface to print a test page, as that works for some reason. Or simply test by trying to print a document, and not rely on using the test page feature you get when you open your printer using Preferences -> Printer & Fax, to test whether the printer works after installing it.

Thanks for posting and keeping track of these issues and tips from all the users.

If you've tried any of this

Print problem to Windows printer over Wi-Fi

Tuesday, September 6, 2011

Chap Tomanek can't print from a Mac to a printer attached to Windows PC over Wi-Fi, and is looking for a suggestion:

I used to be able to Wi-Fi print from a Snow Leopard MacBook to my shared HP 4215 printer shared under Windows XP. It prints from Win XP command. I just did a reinstall of Win XP desktop. Printer HP 4215 is plugged into Win XP desktop. The Wi-Fi is provided by a Motorola router.

The MacBook picks up the Motorola Wi-Fi Internet signal and can see the Win XP desktop and is part of the home network. The MacBook will not Wi-Fi print through the desktop Win XP. I have tried several delete -reinstall the HP 4215 software in MacBook laptop. I can print to HP4215 from MacBook Snow Leopard only if I plug the HP printer directly into the MacBook and select the wired HP printer as the default printer.

The HP 4215 makes noises as if it were about to print, yet nothing happens. Wi-Fi signal appears to travel from MacBook--> Wi-Fi router --> WinXP desktop --> hard wire --> HP 4215.

The HP display screen reads "printing" but nothing prints, it freezes, hangs up. I used the HP website diagnostic utility. It shows a red "X" at the printer queue and it fixes the queue. When I try to Wi-Fi print from MacBook to Win XP desktop server, the HP 4215 freezes. This happens repeatedly after many reboots and many deleted queues.

If you have an idea on what might be going on .


Slow or no NAS storage connections with Snow Leopard |Top of Page |

Wednesday, September 9, 2009

Two readers report problems with network attached storage (NAS) devices and Snow Leopard. A number of readers had previously reported problems with Leopard, since the Mac OS X 10.5.7 update. Nick Bensema sees the problem with both SMB and AFP:

I'm experiencing problems with Snow Leopard and my Buffalo LinkStation NAS device. I had a couple of network folders in my sidebar, and I used to be able to click right to them and it would show the whole directory -- maybe it would take a few seconds to sync up if it was for the first time that day. Now, it takes about ten seconds to sync up the contents of the folder every time I visit it. It's a large folder full of jpg and gif images.

The problem persists whether I use SMB or AFP to connect. The LinkStation supports AFP but doesn't recommend it for modern MacOS machines. But when I use SMB, it displays the same "old-school CRT with blue screen of death" icon that it does for Windows boxes, and folder color labels don't carry over.

Matt Whiting gets an Error 36 and a spinning beach ball:

I too have this problem, although different symptoms to James Spencer, as follows: - constantly spinning 'clock' in the Finder window whilst trying to list long directories (e.g. my iTunes Music folder), with no listing displayed. iTunes can still play music from these directories, though, and I can browse them through Terminal. - error -36 when trying to write to ANY directory on the share (i.e. even the shorter ones that are visible).

I am using a cheap Landisk NAS box, which I believe may run some sort of BSD - and probably an old version of Samba. It worked fine, albeit slowly, under Leopard.

If you're having problems connecting Snow Leopard to NAS devices

TIP: Workarounds for Snow Leopard/NAS problems: use web browser, and Revolution #9

Friday, September 11, 2009

Two readers shared two very different workarounds to Mac OS X 10.6 problems connecting to network attached storage (NAS). One reader uses a web browser to type a path. Another found that the problem partially resolved after he installed iTunes 9. A third reader forwarded some German-language links for our German speakers.

Matt Whiting fowarded the web-browser workaround, which also fixed the Finder problems:

You may want to add the experience and work-around that I discovered this morning. I'd not made any progress with this (and the new iTunes was still hanging), and was resigned to waiting for 10.6.1 (which according to the rumours, may address Finder issues with shares). But then I discovered an extremely odd work-around: before trying to browse the share in the Finder, go to the directory via a browser, Firefox in my case, and in my case the URL is file:///Volumes/Media/Music/. This displays the folder just fine (as per going via Terminal). But subsequently, the share is available via Finder too! How weird is that?

We agree, that's pretty weird. But so is John Harris's fix, who found that iTunes 9 partially worked:

I have a WAG54GS Router and hanging off of it is a 1 TByte FAT32 disc which was accessible prior to Snow Leopard. Strange thing is I downloaded iTunes 9 on 09/09/2009 (no coincidence I hope) and it recognizes my server disk and music on it. I am in no technical but I find this very strange when the normal Go/Connect to Server does not work. Using the Finder route and stored username and passwords gets me nowhere.

(As John Lennon said on the White Album, number 9, number 9, number 9...) If you've tried either of these fixes for NAS storage

Marcus Kammerlander sent us some links about the problem a couple of German-language forums:

It seems it's a larger problem and a lot of NAS are included. In the German apfeltalk forum is a thread and on MacBug.de.

Reports of more NAS drives not connecting in Snow Leopard

Friday, September 18, 2009

We continue to receive reports of Mac OS X 10.6 not connecting to network attached storage devices. The problems occur with both AFP and SMB sharing.

Dennis Ostrovsky can't connect as a guest:

I have an Addonics NASU2 unit which has a 1TB HD plugged into it. In 10.5.8 I had no problems connecting to it as guest, which I have enabled. Now in 10.6.1 (and 10.6) it will not allow me to connect as Guest, claiming that the server does not allow guest access, which it does. I have not changed anything on the NAS since upgrading to SL. I tried adding an account with a password to my NAS and it still won't connect! Something is just really screwed up.

Frank van Brenk sees the error -36 message:

I have the same problems as Matt Whiting. I can browse my Freecom Network Disk but when I'm opening files I get an error "An unexpected error occurred (error code -36)."

Malcolm Heath finds that the Finder stops responding:

I have a new iMac with Snow Leopard installed and have the same issue with a QNAP NAS device. Connects OK and can view the first directories but if I browse to a subdirectory then Finder stops responding.

If you know of a workaround that works

Note: there is now a suggestion for this problem below.

More on Snow Leopard NAS problems: error -36, Time Capsule not exempt, iTunes 9, and a workaround

Monday, September 21, 2009

Today we a number of reader reports regarding Snow Leopard's problems accessing network attached storage (NAS), with both SMB and AFP protocols. The problem seems affect many different brands and models, including Apple's Time Capsule. The 10.6.1 update has not fixes the issue.

Vas had a workaround that worked until the 10.6.1 update:

Accessing NAS constantly getting errors 36 and 8072. Workaround which I hope is temporary is CyberDuck ftp login. It was working fine until recently even in 10.6.1 and then it just all but crapped out.

Dirk Moeller tried using aliases to connect to his Time Capsule:

I upgraded my MacBook Pro from Mac OS 10.5.8 to Mac OS 10.6 and now to 10.6.1 I use a Time Capsule 1GB as a NAS over Ethernet. I had aliases on my desktop to connect to some folders. With Snow Leopard it's impossible to get a connection, the original is missing (but I can get Information of my folder with this alias!) If I connect with the Server on the left side of the Finder I get a connection, but it not stable, sometimes it works for 10 minutes, sometimes only for a minute.

Someone told me to connect via SMB, and it works, but even then the Alias works only sometimes! I made a screenshot-film ( MB) https://dl.getdropbox.com/u/943870/TimeCapsule.m4v

While one reader previously reported that iTunes9 fixed his problem, Craig McBain thinks problem may have begun at the time he updated to iTunes 9:

I too am having a problem accessing my NAS files. I am using a WD Mybook World Edition 1TB and using SL 10.6. I think (although not too sure) that my problems started when I installed iTunes 9.

I can see my server in the 'Shared' section of Finder and but when I try to connect to it I cannot see the shared folders. iTunes can still see all the shared music on the NAS and I can still access it via Safari (the admin pages) but Finder cannot see anything on the drive.

After updating the Firmware for the NAS, the only change was that I can now see two entries in my 'Shared' section in Finder: both the same name but the second one has '-Back-Up' after the name. Still no access to the shares.

I have tried the suggestions at your site but still no luck. I cannot see any of the existing shares. If I create a new share, I can see that! I cannot get into the old shares to transfer the data to the new one!

Tommy Birchett sees the error -36 with a NetApp Filer device:

We are getting this error when we copy files to our NetApp via CIFS using 10.6.1. The Finder can't complete the operation because some data in "filename" can't be read or written. (Error code -36). The file copies, but I believe the extended attributes are stripped. I discovered this link where someone else with a netapp is having the same issue.

Bill Ambrose is seeing very slow connections:

I have seen your page. I have a Buffalo network storage attached, with a Windows network running off SMB 2003. Worked (just - bit flakey often dropping connection) with 10.5.8. Doesn't connect at all in Snow Leopard (well connected once very briefly but lost again almost straight away) SMB2003 is accessible but usually takes 3 tries at about 2 minutes each to get connection working. I would have though Snow Leopard would improve connectivity. Opposite seems to be true.

Chris McGonagle's other computers can access the device, but Snow Leopard can't:

I was just reading your page and I am also reporting (like Matt Whiting) that I am getting an Error Code -36 when trying to access a Freecom Network Drive from within Snow Leopard. It must be the upgrade as my wife's PC and Xbox Media Center can still connect to the device.

Keith Smith forwarded the Console log entry:

I have just installed Snow Leopard and now cannot read or write files to my Landisk NAS drive. My Mac sees the drive just fine and shows the folders that can be browsed but no files will load or can be written. This generates a 'unexpected error (error code -36) and the respective application cannot be opened. Updating the Landisk firmware to NAS-BASIC48B6, loader 69 has not solved the problem. The Console logs show the following log: kernel smb_maperr32: no direct map for 32 bit server error (0xc0000161).

Slow SMB Snow Leopard access to Time Capsule; no AFP access

Thursday, October 8, 2009

Dmitry Krapivin verified a previously reported problem with Snow Leopard AFP and SMB problems accessing Apple's Time Capsule:

Absolutely the same problem exists for me on my MacBook Air! I cannot use my Time Capsule disk via AFP. And via SMB it mounts, but the connection is very slow.

Reader verifies numeric password tip for Snow Leopard SMB NAS

Thursday, October 8, 2009

Jon Harris found that the tip about using numeric passwords worked for network attached storage. The tip originally was reported for file servers. Harris said:

I encountered this same reported problem trying to access SMB shares on my NAS (D-Link DNS-323) having upgraded to Snow Leopard. I'm only on a small home network, so no fancy domains or name servers. I tried the numeric password fix and it solved the problem - although I'm concerned that a numeric password is not as secure as a full alpha numeric one, so would be hoping for Apple to sort this out.

More on fixing Snow Leopard SMB NAS problem with numeric password

Monday, October 12, 2009

Philomeno Cappador verified that using an all-numeric password fixes Snow Leopard problems accessing network attached storage (NAS) via SMB:

I have an iOmega NAS and recently upgraded to Snow Leopard and noticed that I could not access any of my password protected shares. I have experienced issues in the past connecting via SMB or CIFS with Leopard (10.5.x), many times my MacBook would just freeze while trying to copy files. I followed the advice to change the NAS share password to all numeric, and it worked.

I suspect this has something to do with the SMB configuration in Snow Leopard. I have experimented with Linux quite a bit and getting SMB to work with Windows or Mac machines is challenging and most of the time it has to do with authentication. I am positive that this issue has to do with configuration at the OS files dealing with SMB in Snow, and I certainly hope for Apple to acknowledge and resolve the issue.

Reader verifies numeric password workaround for Snow Leopard SMB

Tuesday, November 3, 2009

Kyle reports success with using a numeric password to fix Snow Leopard problems accessing network attached storage (NAS):

In regards to your helpful page I used numeric passwords on my western digital NAS and it worked.

More sucess with "139" logon workaround for Snow Leopard SMB problem

Tuesday, November 3, 2009

Five more readers report success with adding port 139 to the SMB file sharing logon (smb://share:139) as a workaround to problems with Snow Leopard accessing SMB servers. One reader said it didn't work. Tyler Gingrich reported:

Snow Leopard "139" SMB server access tip port trick worked once but after I unmounted the drive, can't get it mounted again.

It did work for Scott Ficek, however:

I was so frustrated that I could not see my Windows Machines. I found your article via Google and it worked like a champ!

Michael Reeves reported success:

I was very happy to come across this tip. This has been the only way for me to successfully access my files. Thanks.

As did Rob Dickerson:

I added port 139 to the SMB address and it worked first time. Thanks for posting this.

And Pastor Russ Troester

Just saw work around on your website regarding using port 139 to access SMB shares in Snow Leopard as I have been having issues at work. I tried this workaround, and it worked immediately.

George Richards:

Just confirming that I tried the port 139 to connect to an smb drive from snow leopard. It worked great.

More feedback on port 139 workaround for SMB file sharing

Monday, December 13, 2010

We have more readers reports regarding the tip "Login with port 139 to access SMB shares with Snow Leopard." Most report success with one form or another. Michael Katchen found that form originally reported didn't work, but another did:

smb://share:139 did not work, but smb://servername:139 worked great! I'm using Windows Server 2003 with a Snow Leopard Mac. Thanks for the info.

It did not fix slow file transfer times for Aaron Muñoz:

I tried using smb://servername.orgname.com:139 to alleviate issues I'm experiencing with slow copy times to Windows file shares, but this did not prove to be a solution.

Kelly Luehrs reports success:

It worked! I needed to connect my MacBook Pro running Snow Leopard to a Windows 2003 Server. I'm not really familiar with Windows, so I was trying to avoid making any changes on that end. This was the only thing that worked. Yay!

Jack Watson: I was successful using port 139 along with domain\user on 10.6 (10A432).

TIP: Fix for 10.6 SMB to NAS error 36 problem: edit smb.config on server

Wednesday, December 23, 2009

Andrew Rowe found a solution to the Snow Leopard problem accessing network attached storage (NAS) via SMB. He added a line to the /etc/smb.conf file to clear up the problem:

Our Snow Leopard upgrade was experiencing was an issue with an SMB connection to a samba-based NAS device (Snap Server 410) joined to a Win2k domain. When the Snow Leopard Macs are bound to Active Directory trying to write files to the NAS device results in the "Error Code -36" message many have seen. A 0-byte file is created, but that's it. Any number of folders can be created without trouble. Reading from the shares is unaffected. If using the CLI, writes to the share are fine, it is only when using Finder.

I got on a hot lead thanks to your reader Tommy Birchett who provided this link. I also found this, which suggested that Snow Leopard is now sending chmod commands to change the Unix permissions. I have observed this to be the case in 10.5.x, noticing that the Unix permissions then trump the Windows ACLs and cause havoc with my Windows users.

I had success by adding a line to the /etc/smb.config on the NAS device: "unix extensions = no". After setting that and restarting Samba, these issues were immediately resolved. Writing files now creates files with proper Windows ACLs instead of just Unix permissions and error code 36 is no longer occurring.

If you've tried this suggestion

NOTE: readers have reported that this fix also works with Linux SMB servers.

TIP: Another take on smb.config fix for -36 file sharing error

Monday, January 25, 2010

We've previously reported a fix for the Snow Leopard SMB file sharing problem that returns a -36 error when copying files. The fix is to add the line "unix extensions = no" to the /etc/smb.config on the NAS device or Linux server. Several message boards are also reporting that there is a similar edit that can be accomplished on the Mac client. Here's one way to do it:

  1. In the Finder, click the Go menu and select Go to Folder.
  2. Enter /etc/ and click the Go button. The /etc/ folder opens.
  3. Look for a file called nsmb.conf and double click to open it. If it doesn't exist, you'll have to create one.
  4. To create this file, open Terminal and type "sudo vi /etc/nsmb.conf" (without the quotation marks).
  5. Back in the /etc/ folder, double-click nsmb.conf to open it with TextEdit.
  6. Type this in the file:
    #######
    [default]
    streams=no
    #######
  7. Save and Quit.

You may have to restart the Mac.

If you've tried this

Reader confirms file-edit fix for -36 error in file sharing

Thursday, May 26, 2011

Hector Correa confirmed a procedure for editing a configuration file to stop -36 errors with file sharing:

I can confirm that your tip 'Another take on smb.config fix for -36 file sharing error: edit nsmb.conf for "streams=no"' took care of the nasty "error -36" on my Mac OS X 10.6.7. This is awesome, I've been dealing with this freaking issue for months and it will be great been able to use my NAS device properly from my Mac from now on. Thanks a lot!

If this worked for you .

TIP: An easier way to turn of streams to fix -36 error on NAS

Thursday, June 16, 2011

Hector Correa updated his previous report with another way to turn off streams to eliminate the -36 error in file sharing in Snow Leopard. Like some other readers Correa could not copy files to a network attached storage (NAS) device. The previously reported fix involved editing the nsmb.conf file to set "streams-no". The easier method involves using "touch" in Terminal. Correa said:

For what is worth, I found more information about this problem and another (easier) way to turn off streams on an article at the Apple site......Read entire story here

TIP: Use Path Finder as another workaround for NAS error -36

Monday, May 10, 2010

Harry recommends using Cocoatech's Path Finder (US $40) to get around Snow Leopard problems accessing network attached storage (NAS):

Download the Path Finder app. On the share file on NAS (public or private user folder) changing the permissions to write, read and execute to folder and enclosed subfolders (for the current user) and you have no more write permissions and Error -36 when you try copy folders or files .

Path Finder is available as a free trial. If you've tried it as a fix for file sharing issues

Reader confirms Path Finder workaround for slow SMB

Friday, May 21, 2010

Bruce Austin verified last week's report that Snow Leopard's slow SMB file sharing problems disappear when using Cocoatech's Path Finder utility instead of the Finder:

I've been plagued with the slow access to SMB files on shared servers, and like so many others on your SMB thread this all began for me when I upgraded to Snow Leopard (i.e. Never had issues with 10.5.x).

Responding to a tip on your site pertaining to NAS error issues, I downloaded a copy of Path Finder, and amazingly, using this navigation interface has resolved my issues of slow-connecting to my company_s SMB servers. In other words, using Apple's Finder = long wait times to mount servers and navigate directories, whereas the same activity using Path Finder I experience no unusual wait times.

My experience with Path Finder suggests the issue is on Apple's side rather than with the Windows 2008 Server that some of your posters have pointed to.

Adobe Bridge as workaround for slow Snow Leopard SMB

Thursday, September 2, 2010

Jason Sloaf suggests another Finder alternative for getting around slow SMB file sharing in Snow Leopard. Readers have previously suggested the Path Finder utility. Sloaf suggests Adobe Bridge:

The other product that gets around the SMB issue in the Snow Leopard Finder is Adobe Bridge. Adobe used to offer an option in the Creative Suite applications to use their own dialog box interface when opening and/or saving a file instead of the Finder's interface. Unfortunately, they seemed to have killed that option off in CS4 (and I would imagine CS5 as well).

The Bridge application is much faster than the Finder in executing file management tasks via an SMB server connection. I'm going to look at Path Finder as well, but Apple's apparent lack of effort to rectify this issue with the Finder just leaves me scratching my head…

If you've tried Adobe Bridge to get around slow SMB in the Finder


Novell AFP Server incompatible with Snow Leopard |Top of Page |

Wednesday, September 2, 2009

A software developer reports that Novell AFP Server is incompatible with Snow Leopard. The Condrey Corporation called it a bug in Mac OS X 10.6 that prevents Snow Leopard from mounting AFP volumes hosted on NetWare and Open Enterprise Server 2 SP1. Whether or not it is a bug in the operating system, Condrey does not claim it is a problem with AFP in general. Group Logic's AFP server, ExtremeZ-IP does not have this problem.

If you've seen any problems with Snow Leopard and AFP file sharing

Reader says Novell AFP Server incompatible with Snow Leopard

Monday, November 8, 2010

Although most of our reports with file sharing problems with Snow Leopard are with SMB, Dan Mazzola can no longer use the old Novell AFP file server for Mac clients:

I am writing to let you know that I cannot connect to Novell now that I have 10.6.4

If you've seen this

TIP: Applescript fix Snow Leopard Novell AFP Server

Monday, November 22, 2010

David Ritter responded to our report Novell AFP Server incompatible with Snow Leopard by sharing an Applescript to fix the problem:

I am a tech support person for a chain of weekly newspapers. We use Novell servers at many of our locations. When installing new Macs running Leopard or Snow Leopard we have found that the only way we are able to connect to the Novell servers is to enable "clear text" logins on OS X.

I found a short AppleScript to help with this. I compiled this to a small script app that we use when setting up new OS X installations......Read entire story here

Reader says Novell file sharing NOT incompatible with Snow Leopard

Monday, November 22, 2010

Garvin Boudle doesn't agree that Novell AFP Server is incompatible with Snow Leopard:

We use Novell Open Enterprise Server (OES) every day from Mac's running 10.6.4 without incident. It just works. Would be helpful to know what version of Novell is being used. OES can actually be installed as either Netware 6.5.x or as a SUSE Linux Enterprise server.

Is this what you're seeing?

TIP: Novell OES 2 SP2 fixes Snow Leopard incompatibility

Monday, November 29, 2010

Pete Fuller commented on the reported incompatibility between Novell's AFP file server and Snow Leopard. He says that a newer version of the server released a few months ago works:

This is an old issue, there are Open Enterprise Server updates that fixes this issue. AFP support was awful in the first release for OES2-SP2, but has been very stable in our environment since the mid-summer patches were released. I'm typing this on a 10.6.4 Mac with AFP connections to several of my servers that have been active since before the weekend.

If you've tried these new patches


Snow Leopard problem saving Office 2008 files to Win server | Top of Page |

Tuesday, September 15, 2009

Craig Chambers is having problems saving Office 2008 files to a Windows server:

I've encountered a problem saving Office 2008 documents to a Windows server (SBS2003 SP2, not RC2 in my case) in 10.6. It looks like I am not the only one having this problem. Please see this post I started at Microsoft.

After upgrading to 10.6 everything seemed to be fine with my Office installation until I tried to save a document that I had opened from a network share. When trying to save a document opened from a Windows share I receive the following error message:

Word cannot save this file. The disk may be full or write protected. Try one or more of the following:

    • Free more memory
    • Make sure that the disk you want to save the file on is not full, write protected, or damaged

The error in Excel is similar, I have not tried PowerPoint but I would expect the same message.

Needless to say the disk is not write protected and the file is not read only. I can open and edit other files in the same folder in different applications, I can even open Word docs in TextEdit and overwrite the file but Office 2008 will not save the file. If I try to save the file to my local drive after the error message is displayed, Office crashes.

I am connecting to the share through the network browser in the sidebar but have also tried the Connect to Server menu and tried both smb and cifs connections. Neither works.

I have removed and reinstalled Office 2008 and run the updates to 12.2.1, I have reboot several times, repaired disk permissions and run a disk check, all to no avail. I am trying to connect with a MacBook Pro 2.4 GHz with 4GB or RAM running 10.6.

I can now create a new document in Word and save it to the server in .docx format (.doc will NOT save at all which is what we use around here) When it saves however is becomes a read only file even though the permissions show that I have read/write permissions on the file (I see this both on the Mac side as well as the server side security properties). At this point I can make a change and do a Save As and it will save, but as a read only again and they have to be .docx files to be able to even do that.

If you've seen this problem

Another report of 10.6 problem saving Office 2008 files to Win server

Friday, September 18, 2009

David Doerksen is seeing the problem with saving Office files from Snow Leopard to Windows servers. He updated to Snow Leopard and Office 12.2.1 at the same time, on an Activite Directory network:

Regarding Craig Chambers' report on the above issue, his experience mirrors mine exactly. Mac Mini running Snow Leopard, Office 2008 with updates through 12.2.1. Document-saving to the Windows SBS 2003 Server worked normally before I did the following:

  • Upgrading to Snow Leopard
  • Joining the machine to Active Directory
  • Installing the Office 12.2 and 12.2.1 updates

After which I put it into production today, only to have this come up within the first hour of use. This is our first Mac machine in a Windows environment.

If you've seen this issue

TIP: suggestion for problem saving Office 2008 files to Win server: disable Autorecover

Monday, September 21, 2009

Responding to reports of problems saving Office files from Snow Leopard to Windows servers, a reader forwarded a suggestion that worked in Leopard:

I had similar problem under Mac OS X 10.5.8; Disabling autosave/autorecover solved the problem.

If you've had this problem in Snow Leopard and tried this suggestion

More Snow Leopard problems saving Office 2008 files to Win server

Wednesday, October 21, 2009

Marco Junge from Germany confirmed the Snow Leopard problem of saving Office files to Windows servers:

I have got installed a SBS 2008 and ,what a luck, I only updated one client to test. The following things I did:

  • Upgrading to Snow Leopard
  • Office 2008 was already installed with service pack 12.2 and 12.2.1

Failures I have seen up to now:

  • I can't save excel documents in xls but can in xlsx
  • If I save Word documents on the server they are marked as read only until I shut down everything.

Previously, a reader reported that disabling autosave/autorecover fixed the problem. If you've seen the problem and tried this approach

Reader says 10.6.2 update doesn't fix problem saving Office files to file servers

Monday, November 16, 2009

Although there were indications that the Snow Leopard 10.6.2 update might fix problems with Office apps saving files to SMB file servers, Antonio Luis Duarte still sees the problem:

We're having same issue. Can't save any Office 2008 file on a volume shared, even with 10.6.2 and the last update of office 12.2.3. We've tried :

  • installing all Macs with 10.6.2, then Active Directory and then Office
  • installing all Macs with 10.6.2, then Office and the Active Directory
  • adding administratives rights to the machine for users--still nothing.

If you've seen this with the 10.6.2 update

More reports: 10.6.2 did not fix the problem saving Office files to Win servers

Monday, November 23, 2009

A number of readers agree with a previous post that the Mac OS X 10.6.2 update does not fix the Snow Leopard problem with saving Office 2008 files to SMB servers. (We've previoulsy posted one suggested workaround, described above.) Rocky Spain describes the issue:

We are still unable to save files to our Windows Server from Office 2008, we can save once but then it is marked as "read-only." Disabling autorecover didn't fix this for us. Mac OS X 10.6.2

Ted Varias said that dragging files to the server works, but saving from Office doesn't. However, the problem doesn't occur with AFP:

We too are having the network file saving problem with Office 2008 and Snow Leopard. Our file servers are Windows 2003 R2, and our affected client machines are running Snow Leopard 10.6.2 with Office 12.2.3. Any Office file that is saved on a Windows file server cannot be saved to the server. It must be saved locally and then dragged to the file server from a Finder window.

This issue only appears to be limited to SMB shares. AFP shares seem to function correctly. This behavior does not occur with any Leopard (10.5.x) clients; they function correctly regardless of the server type.

Ben McEniery in Australia:

I also have this problem. The problem remained after the upgrade to Mac OS X 10.6.2.

Jacob Piotrowski:

Our company has also been experiencing a very similar issue too this with our first 10.6 Mac being here. We recently purchased a new Mac that was running 10.6.1 and Office 2008 (12.2.1). Our main file server here is running Windows 2008 SP2. Though we have also reproduced the issue connecting to an old file server running Windows 2003 R2. Whenever the user opens a file with either Word or Excel (have not tested PowerPoint since she does not use it anyways) it creates TWO locks on the file on the file server. It is like the user has opened the file twice which then creates a lock on the file. It is not labeled as read only in the title bar, but if she goes to save it will not allow her since the file is in use.

If we open the documents with anything else (such as text edit) they work fine.

I have tried unbinding and rebinding the machine to AD, uninstalling and reinstalling Office 2008, upgrading Mac OS to 10.6.2 now and Office to 12.2.3. Same result along the way. This issue is not affecting any of our other 10.5.x machines on the network which leads me to believe this is a 10.6.x issue. Also as a side note this user has a second machine running 10.5.6 and Office 2008 and has no issues on that machine.

We've previoulsy posted one suggested workaround, described above.

Microsoft and Apple said to be working on Snow Leopard/Office 2008 file saving problem

Monday, November 30, 2009

Craig Chambers reports that his conversations with a Microsoft representative indicate that Microsoft and Apple are both aware of the problem in Snow Leopard of saving Office 2008 files to SMB servers. Chambers sent a report about his communications that included these points about the problem:

  • It occurs on with Macs bound to Active Directory networks
  • It occurs with the legacy file formats (.doc .xls and .ppt) as well as with .docx, but not with .xlsx and .pptx.

Chambers' report includes some theories on what might be happening:

I was one of the original posters that contacted you about this problem. After installing 10.6.2 the problem briefly disappeared but alas the problem came back. This only happens to Macs bound to Active Directory.

I have an open case with Microsoft support and this is what we have discovered so far.

1. According to the Microsoft rep that has been put in charge of all cases related to this issue, it seems to be a problem with Apple's implementation of the SMB protocol.

2. One reasons that it may be affecting only Office is related to how Office uses temporary files. I am not sure if I have this exactly right, but I was told by one of the techs that MS Office writes data to a temp file on the server and then when you choose Save the data is replaced with the real file. This is why a byproduct of this problem is 0 Kb temp files left after the file save fails.

3. Users of Thursby's DAVE do not appear to have this problem which would backup the assertion that it is related to Apple's SMB client.

Right now it looks like Microsoft is working with Apple's engineers to resolve this problem and the most likely outcome for a fix is a software update from Apple.

Someone at Apple thinks POSIX may be related (Microsoft denies that Office works this way). The good news is that they have finally been able to replicate this issue on a test server so hopefully that will help with the progress with this issue.

I personally believe that we may be looking at a couple of bugs on both sides that do not cause problems in themselves but together create this situation…it also appears to be at least partly Microsoft related as all of the legacy formatted documents have this issue (.doc .xls and .ppt), but of the new xml based documents (.docx, .xlsx, .pptx) ONLY .docx is having this issue. This would seem to me to imply that there is some coding difference between the way .docx files are handled versus the rest...

As an aside, my Microsoft support rep forwarded a note from Apple to me. At this point we think it is unrelated to our current issue as the engineers at Microsoft say that Office does not work the way Apple describes in this passage. I include it in case it can shed a light on other issues that this may cause. From Apple:

"So the read-only "docx" issue and part of the "doc" issues have to do with POSIX modes. We have no real posix modes if the servers doesn't support UNIX extension. If we are in a managed realm we use ACLs and dummy up the POSIX modes to be 0777. If we are not in a managed realm, then we set the uid/gid to the user that mounted the volume and set the posix modes to 0700.

Now we do have a bug in our create call where we could return posix modes of 0000. In this case the ACL is correct and gives the user full access. Looks like office is looking at the posix modes and making decisions based on those modes. Now with that said we shouldn't be returning POSIX modes of zero here. This is caused by the fact that we are setting the UID/GID to the mounted user in the create routine. This code should not be setting those fields."

Benoit in France also sees the problem with Excel .xls files, but not .xlsx:

We are experiencing the same issue with the snow leopard 10.6.2/office 2008 12.2.1 and windows 2008 file Sharing. Have you a tip to modify and save an .xls file (and not to be obliged to save it as .xlsx)?

More on disabling Office 2008 Autorecover for Snow Leopard file saving problem

Monday, November 30, 2009

We've had some comments on the suggested workaround for the Snow Leopard problem saving Office 2008 files to SMB servers. Gopal Patel said it didn't work:

I tried the workaround of disabling autosave/autorecover mentioned at your site. That did not solve the issue, if you want to let others know.

Several other readers asked how to disable this in Office 2008. Here's how: In and Office app's Preferences, click the Save icon, then uncheck "Save Autorecover info every ____ minutes."

Theory on Snow Leopard problem saving Office 2008 files to Win server

Thursday, December 10, 2009

We have five more reports on the Snow Leopard bug that prevents users from saving Office 2008 files to SMB servers. (AFP servers do not have this problem.) Krister Laag has a theory. Like some other users, Laag sees this only in Active Directory domains:

It appears that only Macs that are bound (and restarted) to the AD gets the problem (I have not tried when the user at logon is authenticated to the AD). When looking at the permissions of a file on the SMB share (from the Mac client), the local users name is in the permissions profile and not the credentials used to log onto the share. If you try (and have the permission) to alter the permissions of that file, the permissions go haywire and require an AD admin to fix it as the file will now have an owner that is not listed in the AD. Unbind the Mac (and restart) and the problem goes away. This is tried on both Windows server 2003 and 2008, both with latest updates.

My personal belief is that it's related to how Office saves the files as there is a copy made and some renaming done in the background. I think the bug really is the same as the 10.6 Finder copy bug.

Tommy Birchett confirms that the problem is with Active Directory and certain file types:

I can confirm that our AD bound Snow Leopard computers with Office 12.2.x have problems saving .xls, .ppt, .doc and .docx files to our SMB shares. Funny thing is I have someone using 12.1.x with Snow Leopard and he is not having this problem. I have not had time to test all versions of 12.1.x and 12.2.x, but it appears possible that older version of MS Office might be OK with Snow Leopard-- at least with regard to this particular issue.

Jason Worf said the problem leaves an unreadable file on the server:

I have the same problem as the user you quoted on your website. It started when I installed Snow Leopard. If I try to save something to the server in a legacy format from Word or Excel it rejects it with this message: "Word cannot save or create this file. The disk may be full or write-protected. Try one of the following: Free more memory. Mac sure that the disk you want to save the file on is not full, write-protected, or damaged."

The process leaves a non-readable file on the server like this: Word Work File D_1.tmp.

Matt Lee reported that the workaround of disabling Autorecover doesn't work:

Just an FYI the auto saving feature does not fix this issue, nor does the recently released Office 12.2.3 patch.

Gregg Sales agreed:

I have this option unchecked. Creating a file in Word and saving it to a Win 2008 server as an domain admin creates a read only file. No fix yet.

TIP: Workaround for Snow Leopard/Office/Adobe file saving problem

Monday, December 14, 2009

Chris Eads reports that a procedure he sent in last week also works to fix the Snow Leopard problem of saving Offices files to SMB servers on Active Directory networks.

I've verified the Office saving issue is resolved with the fix I found for the Adobe suite. I tried saving files out of office 08 to a non-mac-friendly share, and then on of the one's we've changed the NTFS owner to NETWORK SERVICE, and doc, docx, xls, xlsx files save fine. Tested on both 12.1.0 and 12.2.3.

If you've tried this approach

Reader success with SMB/Office workaround

Friday, December 18, 2009

Several readers responded to the workaround we reported on Monday for the Snow Leopard problem saving Office files to SMB servers in Active Directory environments. Randy Tamura reports success with the workaround :

I tried the work around of making the owner "NETWORK SERVICE" and it worked for me. I tried both xls and doc files and they both saved to the SMB directory and also to subdirectories of the shared directory. I'm running 10.6.2 on the Mac and WinServer2003.

Anthony Gomez had a question about the security of this solution:

I can confirm that while a Mac is bound to AD server it has trouble saving MS Office docs to directories on that server, and turning off AD binding from the Mac will correct this problem.

I have a question about Chris Eads fix though, as he mentions on Thursday Dec 14th, and I'm maybe "NEW" in asking this, but how does changing ownership of the shared directories to "Network Service" effect the security of those same directories; also how does this affect how other things behave with regards to those directories having "Network Services" as the new owner.

If you know the answer

The workaround didn't work for Allen Escobar, and he sent some observations:

I was glad to see the posting by Chris Eads and the suggestion about making NETWORK SERVICE as the owner of the folder, unfortunately after trying his suggestion it does not appear to be working for me. I am not sure if I just didn't follow his suggestion correctly or if the fact that I am running Windows Server 2008 (in a VM environment) and not Windows Server 2003 that makes a difference. I am still having this same issue on the two Macs that I have joined to our domain - each one is running 10.6.2 and Office 2008 and the users are logging in with their Domain accounts.

Here are some odd things that I do want to point out in attempting to troubleshoot this issue:

* Both Mac users can save files to their Home folder without any issues. Since they are part of the domain I have their Home folders redirected to a folder on the same network/server. By this I mean that their Home folder is redirected in the same fashion as a Windows user has their My Documents folder redirected to a location on the server. I believe this is what is referred to as a Mobile Account/Login.

* Even when logged in with an account that has both Domain and Local Admin privileges, the results are the same. So is it a privileges or authentication issue?

* This I think is the oddest part that I have noticed about this issue, which I hope I can explain correctly - I open Word 2008 and create a document which I save to the Windows server without any issues, of course after which the file becomes "READ-ONLY" once it is saved. However, what I noticed is that regardless of the permissions that the file has, if I select the file that was saved to the server and "Get Info" for the file, I am able to reopen the document without it being READ-ONLY. This then allows me to make changes to the document and resave it as you would normally be able to, of course the file once again becomes READ-ONLY after resaving it. I can repeat this step over and over without making any changes to the file or folder permissions. My thought is that when you query the file info, it sort of rewrites the correct permissions to the file which allows you to open the document as you normally would open any document.

It also works when you query "Get Info" on the folder that contains the documents. Doing so allows you to open every document contained in that folder without it being a READ-ONLY file, of course it still holds true that once you resave the file, it reverts to READ-ONLY again, but the other documents are still ok until you open and save them also.

Confirmation of tip for saving Office files to SMB servers in AD networks

Wednesday, February 24, 2010

Chris Ellis confirmed a fix for the Snow Leopard problem of saving Office files to Windows servers in Active Directory networks:

I can confirm that changing ownership of the SMB share on Windows Server 2003 to NETWORK SERVICE solves the issue for my network where I have Macs bound to Windows Active Directory.

However, others have reported less success with this suggestion.

Saving CS4 and Office 08 to an SMB share in Snow Leopard not working locally

Thursday, January 14, 2010

Brian Leight found that that a workaround for SMB problems with Adobe CS4 and Office didn't work for local servers, but did work for remote servers:

I tried the fix listed by making the owner "Network Services" and it does not work on my local servers, however we have offices in LA and I am able to save to those servers (we're in New York). It seems there is a latency issue at work where it needs time to send the .temp file and then delete and replace with the real file. I hope that 10.6.3 fixes this issue for good cause my users that I have moved to SL are in an uproar.

If you've seen this

Note: for more reader feedback on the "network services" tip, see our Snow Leopard and Active Directory Tips and Reports page.

TIP: Another Fix for SL Office 2008 on SMB server read-only issue

Monday, January 11, 2010

Cheers Reuben send in a solution for resolving the Snow Leopard problem saving files to Windows file servers. This problem occurs when saving a document within Word. Reuben's fix involves Terminal:

I recently found a solution to this problem I've been having with Office after upgrading to Snow Leopard. Create a new folder on your server. COPY (not move) a folder with your work into this new folder. Use Terminal to change the permissions of the folder you copied, (by default I had no access whatsoever):

  1. Type sudo chmod -R 777, leaving a space after 777.
  2. Drag the folder into Terminal and press Enter. You will also need to type your password.

Voila! I can now open all Word docs regardless of .doc or .docx

You can then delete the original and move the new folder back to it's original location.

PS I also changed the default file locations in Word by going into the Prefs, select File Locations and enter in a location for the Document setting on my computer eg Documents folder or Desktop. However, I don't think this had any affect on the result.

If you've tried this

Office update temporarily affects saving Office 2008 files to Win server

Tuesday, March 16, 2010

Gorski is seeing the Snow Leopard problem of saving a files to Windows Server from Office 2008, where after the initial save the file becomes read-only. He thought it was fixed with the recent Office update, but the fix was fleeting:

I just patched my Office to 12.2.4. For a bit, I could open and save Word .doc and .docx files on my Windows server, but I can't recreate the success now. Microsoft and Apple work in mysterious ways.

We've previously posted several suggestions from readers to workaround this issue. One was to disable autosave/autorecover. Another was to change the NTFS owner to NETWORK SERVICE. A third involved using Terminal to change permissions of a particular folder.

10.6.3 fixes Office/Adobe saving problem to NetApp server

Tuesday, March 30, 2010

Tommy Birchett reports that the Mac OS X 10.6.3 update fixes the problem of copying files to SMB servers from Office and from Adobe applications:

10.6.3 update fixed our problem with saving Photoshop CS4, Illustrator CS4 and MS Word docx files to our NetApp server shares. We never implemented any of the SMB workarounds suggested here.

Readers verify 10.6.3 fixes Office/SMB file share bug

Friday, April 2, 2010

Two more readers confirmed that the new Mac OS X 10.6.3 update fixes the problem of saving files from Microsoft Office and Adobe CS4 applications. Nick Carpenter reported:

I can verify that 10.6.3 fixed our SMB issues in a Windows 2008 R2 domain environment (machines bound to AD) for both Microsoft Office and CS4 apps. We previously could not save to the file server from the apps and now can.

Travis Glessner found the same with a storage area network (SAN) device:

We have had this problem since Snow Leopard came out. You could save the Word document one time to the SMB share on an EMC SAN, but if you hit save again, it would say the file was read only. Finally, 7 months later, Apple has fixed the issue. If you upgrade to 10.6.3, MANY problems are fixed, including the SMB Word sharing problem. I have updated three Snow Leopard machines to 10.6.3 and all are now able to update their Word docs on the SMB share to the EMC SAN.

If you've found that the 10.6.3 fixed any of the cross-platform problems we've been reporting


Snow Leopard Finder not updating Win Server | Top of Page |

Friday, September 18, 2009

Christian Volk finds that Snow Leopard Macs are not updating Windows server folders in the Finder:

SMB shares out of Windows 2000 Server don't update properly as long as a Snow Leopard machine has attempted to delete a file or folder. Even viewing from the server, the file is "locked" until Snow Leopard logs out of the share, at which point everything updates correctly, such that a deleted file actually disappears. When Snow Leopard logs back in, it sees a correctly updated directory.

If you've seen this problem

More on Snow Leopard Finder not updating Win Server folders

Wednesday, September 23, 2009

Justin Parmer added another observation about the problem with Snow Leopard's Finder not updating Windows server folders in the Finder:

I just found your site looking for a solution to the same problem posted today by Christian Volk. We are having the same issue with our Windows 2003 server since upgrading to Snow Leopard. One thing we're experiencing not mentioned by Mr. Volk is how inconsistent this behavior has been. We are seeing this most of the time, but sometimes we can delete a folder and it disappears as expected.


Slow Snow Leopard SMB connection to Win server | Top of Page |

Friday, September 18, 2009

We've had reports of slow Snow Leopard connections to network attached storage devices, but Ron Breton is seeing this with a Windows server:

I have an iMac running 10.6 and connected to a server running Windows Home Server (WHS). Everything is hard wired, no wireless. Until 10.6, everything worked nice and fast. Now sub-folders take really long to open, sometimes upwards of 10 seconds.

This is most definitely an issue with Snow Leopard.

If you've seen this problem

More on slow Snow Leopard SMB connection to Win server

Tuesday, September 22, 2009

Several readers responded to the problem of slow Snow Leopard SMB connection to Win servers. One reader said typing the path solved the problem, another said it didn't. Don Wershba said that not connecting through the Finder resolved the issue for him:

My fix was to connect directly via the "Connect to Server" (Command-K) and not use an alias of the server. Connecting in that manner resolved all speed issues - Folders and files display immediately (probably as much faster than 10.5 as I see others improve). A bit of a drag that I cannot utilize a Desktop Alias for my server anymore, but I'll take speed over convenience any day!

Sven Geisler, however, still sees slow performance when using a path:

I do have the same issue. I'm running a Windows Server 2008 SP2 as file server. I have three iMacs which using the Windows file share with 'smb://<hostname>/<path'. The network is a switched gigabit-network - no WiFi. Everything works very well until I installed 10.6. It takes very long if you open a directory before the Finder does show the content of this directory. I left one iMac on 10.5.x and this Mac works still very well and doesn't have this issue.

Stephen Walton sees slow SMB access on two Macs, as well as other SMB problems:

I have exactly the same problem, both on my iMac running 10.6 and on my MBP running 10.6.1. Also the MBP running 10.6.1 will not mount any Win Server drives. No problems in 10.5.8.

Reader's SMB Windows browsing still slow in 10.6.2

Monday, November 23, 2009

Tom Waterhouse in the United Kingdom reports that the Snow Leopard 10.6.2 did not fix a problem with slow access to Windows servers:

Although 10.6.2 fixed Windows server browsing for some, my problem still remains after the update. I've had full access to our Windows servers here since 10.6, however compared to 10.5 performance was very poor. Every now and then the Finder (or any application trying to access the server) will pause, appearing to be waiting to reconnect to the server.

If you've seen this problem

More reports of slow Snow Leopard SMB browsing/file copying

Monday, January 11, 2010

Four readers responded to SMB Windows browsing still slow in 10.6.2, with tales of slow browsing as well as slow file transfer with large files in Snow Leopard. Callum Spence reported:

Regarding Slow Snow Leopard SMB connection to Win server, this is a very frustrating bug in 10.6. I have a large amount of data saved on a Windows server that I continuously access and each time I open a different folder it takes 10-25 seconds to show the contents.

Jan Willem Heining in Amsterdam had the same problem:

I'm having the same problems as mentioned in the update of Monday, November 23, 2009. The configuration of my MacBook Pro is 10.6.2, 2.53 GHz, 4 GB RAM

Jeremy Varnham only sees the problem with large files over 5 MB in size:

At work I am on a large Windows-based (Active Directory) network, I don't know what version. The management has recently been generous enough to buy me the latest i7 iMac with maxed-out specs. It is running OS X 10.6.2. My computer is not bound to the Active Directory, but I can browse network shares, and have saved the credentials in my keychain. I can access the SMB shares either by Command-K or by clicking on a shortcut I put in the Finder toolbar.

Browsing the directory structure on the SMB share is usually fast; however, if I copy a file over approx 5Mb in size the Finder becomes almost unresponsive (beachballing) and the file takes an unreasonably long time to complete. Files over 100Mb will not make it - the Finder hangs completely. While a file is copying, it is almost impossible to browse the share, or if the file is large, even to browse local folders.

Occasionally I have the issue where deleted files remain visible until I disconnect and reconnect to the share.

Aaron Green:

I was reading the site for the first time and I wanted to tell you that I am also having the same problems with SMB connections to my SBS 2008 server. I am an IT admin using a MacBook Pro in a completely Microsoft environment. Before I had Snow Leopard everything was pretty fast, but now connections are a pain in the butt because they take too long. And when I do finally connect to the share, on a wired network connection, copying files is painfully slow, it took me hours to copy 2 GB of data from my computer to the server, hardly fast for state of the art computing.

Slow Snow Leopard SMB access continues with 10.6.3

Monday, May 10, 2010

Two readers report that very slow Snow Leopard access to SMB shares continues in version 10.6.3. Chay Wesley sees it with a Windows server:

Just found your website while Googling for a solution to the problem I'm having since installing Snow Leopard. Very long waits for Finder to connect to a Windows Server 2008 SMB share. It does always connect eventually, but waiting for it is maddening. This behavior continues to persist even with 10.6.3 installed. No problems with 10.5.x.

Lee Campbell sees it with a Linux server, but the delay is reduced in a Windows domain:

I have mounted my Windows server both from Boot Camp Windows 7 and Snow Leopard. From Windows, the mount happens, and Explorer populates the drive view instantly. In Snow Leopard, my mount takes about 10 seconds to happen, and then once it happens, it takes another 10 seconds to before Finder shows any files.

I am mounting a Samba version 3.4.3 running on Debian linux with authentication coming from Active Directory. If I mount a different server serving the same file system but with a Windows NT 4.0 domain controller, then the first 10 second pause is almost eliminated, but the Finder is still very slow to display any files.

Windows clients mount both samba servers instantly.

This problem first appeared when I upgraded to Snow Leopard. I'm running 10.6.3 with all patches.

If you've seen this problem


TIP: workaround for Slow Snow Leopard SMB connections: sysctl, ack=0

Tuesday, May 18, 2010

Ricardo suggested a work around for the Snow Leopard problem of slow browsing of SMB file shares. He recommends typing a command in Terminal:

I am on 10.6.3 and I am still experiencing this problem. I've got about 250 Gb of MP3 on a Windows XP share, and while adding files to the iTunes library I have to go add a few folders at a time. I found the follwoing to be a potential solution, while it made it better, I still have problems:

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

The original setting is ack=3. This has something to do with samba, but I'm not sure what.

If you've tried this

Reader says sysctl tweak helps with slow SMB

Friday, May 21, 2010

Tom Waterhouse reports some success with Monday's suggestion for improving Snow Leopard's SMB browsing speeds:

Just to say that we've tried this terminal tip:

"sudo sysctl -w net.inet.tcp.delayed_ack=0" on two of our Macs in our office (of which runs on various versions of windows server) and it seems to help.

Our systems admin didn't like the sound of setting it to "0", so we're running it at "1" and it seems to make a bit of an improvement, but still runs slowly now and then, albeit rarely. Thanks for the tip!

If you've tried this

Mixed results for sysctl workaround for slow SMB; AD involved?

Tuesday, May 25, 2010

Ben West reported success with last week's suggestion for resolving slow SMB file sharing in Snow Leopard:

I ran the sudo sysctl -w net.inet.tcp.delayed_ack=0 command on my iMac which is accessing a Windows Server share over a VPN connection. This solved my slow browsing SMB issue completely.

However, the workaround did not work for Guillaume Dasnon in France, but he points out that the problem only occurs with Active Directory:

I tried the command "sudo sysctl -w net.inet.tcp.delayed_ack=0" with a reboot after it but it did not work fine : the problem is still there.

I am surprised because when I typed the command "sudo sysctl -w net.inet.tcp.delayed_ack=3" after the reboot to restore the previous settings, I saw that the system had yet restored them, as if the new settings were not stored in the system.

My environment is Mac OS X 10.6.3 on MacBook Pro; Server is RHEL 5.4 x86_64, samba-3.0.33-3.28.el5, integration in Active Directory via samba, winbind and kerberos (no ldap).

Note that there is no problem if client is Mac OS X 10.4/10.5 or Windows XP - the same server configuration without AD integration works fine with Mac OS X 10.6 client.

If you've seen this behavior with our without Active Directory

More success with sysctl tweak for slow SMB

Tuesday, June 22, 2010

Like some readers, John Stanfield found that a Terminal command we posted fixes slow SMB performance in Snow Leopard:

Regarding slow, Snow Leopard SMB Browsing, this seems to have worked for me:

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

However, not all readers have had success with this. To start a discussion, post a note in our new Snow Leopard File Sharing forum.

Reader tests different ACK settings for slow SMB

Tuesday, June 29, 2010

Kent Gaskill commented on the previously reported tip to use sudo sysctl -w net.inet.tcp.delayed_ack=0 to improve Mac OS X's SMB file sharing speed. He tested different settings on Leopard, and found that ack=0 was actually the slowest. The fastest was ack=1:

I have a small art department with five computers. Currently I have all iMacs, running OSX 10.4.11 (2 computers), 10.5.8, 10.5.6, and 10.6.2. We are using Ethernet to connect to our Windows 2003 R2 Server. Currently, I have experienced extremely slow transfer speeds...For example, a file that is 800MB will take 30 sec. (on the normal IMacs) but on the others (that are acting up) it is taking up to 4 minutes.

I tried using this command: sudo sysctl -w net.inet.tcp.delayed_ack=0 . I tested transfer speeds on my OSX 10.5.8 machine, setting the ACK to 0,1,2 and 3 with a 534 MB file:

My results were as follows:

  • ACK 3 --> 35 sec
  • ACK 0 --> 43 sec
  • ACK 2 --> 25 sec
  • ACK 1 --> 13 sec

ACK 1 was the best but still only half as fast as my OSX 10.4.11 machine that did it in 6 seconds. For a 1 GB file that's the difference of waiting 3 min and 6 min. If I was using the default ACK 3 it would the difference of 7.5 min and 3 min! Very bad indeed.

Meanwhile, John Stanfield updated his previous note, where is reported success with ack=0 in Snow Leopard. It no longer works, and he has a new problem:

I guess this isn't working for me after all...today it's taking forever to display folder contents and saying I don't have permission to move files.

If you can comment

TIP: Getting ACK=0 to stick through reboot for slow SMB

Tuesday, July 20, 2010

Chris Thompson provided a way get a workaround for slow SMB connects to be retained through a report: edit the /etc/sysctl.conf file.

The sysctl -w net.inet.tcp.delayed_ack=0 tip worked for me. I found all these posts interesting and helpful as I have been looking for a fix for the slow Windows fileshare browsing issue for quite a while! I will probably try the Windows server registry hack as well: http://support.microsoft.com/kb/328890/en-us

To make the setting "stick" through a reboot, you need to edit the /etc/sysctl.conf file by adding net.inet.tcp.delayed_ack=0 to it.

You can edit it with vi in Terminal as root or TextEdit by doing Go to Folder -> /etc.

I noticed that the Windows article asks you to set the delayed ack to "1" and one of your other posters stated that the best performance for the sysctl command is also "1." There must be a connection, I think.

If you've tried editing the syscts.conf file

TIP: ACK! Slow Mac access to Win servers -- a server workaround

Tuesday, June 15, 2010

Adrian Pinderhughes shared a server-based approach to slow Mac access to Windows servers. It has to do with the TCP Acknowledgment (ACK) behavior in the TcpAckFrequency registry entry of the server. Previously, a reader sent in a workaround for slow SMB access to Windows servers that acted on the Mac client side. This was to use this command in Terminal: sudo sysctl -w net.inet.tcp.delayed_ack=0

Pinderhughes deals with this on the server's registry:

I saw your thread on a message board. While indirectly related, we have software that runs slowly in such an environment. While making the change on the client side has helped, we have seen dramatic speed increases when making a change on the server side, as described by Microsoft. There is more info regarding the cause of this issue here.

If you've tried this approach

Workaround for slow SMB file sharing, sysctl, ack=0, works on large files

Monday, March 21, 2011

Although the tip "Workaround for Slow Snow Leopard SMB connections: sysctl, ack=0" doesn't work for everyone, it does work for Michael Smitasin for very large, multi-gigabyte files. He sent some test results:

We were seeing extremely slow download speeds over wireless when connecting to a fileserver via SMB (Windows Server 2008 R2) using newer Macs running 10.6.6. The estimated times were 7-8 hours for a 5.8 GB file, or about 20 kb/s. After performing this command:

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

We saw speeds improve considerably. Now estimated times are about 50 minutes, with speeds around 1.5 mb/s.


DNS/kerberos setting workaround for slow SMB browsing

Tuesday, June 29, 2010

Kyle Rabe offered another approach for fixing slow Mac SMB file sharing problems, but is asking for feedback. He believes that on his Macs, slow SMB file sharing is due to the Mac waiting for a response from a DNS server regarding. He created a kerberos file on a Mac and included the line the setting "dns_fallback = no." Rabe's report:

I've been following the MacWindows.com tips and workarounds regarding slow SMB connections from Snow Leopard to Windows Server 2008 for a while, and so far, the tips have not made a difference for me. I did some packet inspection using Wireshark, and I noticed that when I try to connect to an SMB share, my MacBook sends a request for a TXT DNS record that matches _kerberos.server.domain.local to the mDNS address (224.0.0.251). Unfortunately, it never receives a response, so it sits and waits for 45 seconds, repeating the request, before giving up and trying something else. In our office, the record exists on our DNS server, but Windows Server 2008 DNS apparently doesn't respond to mDNS broadcasts. While I'd love to offer a server-side fix, I feel more comfortable with an easily reversible client-side workaround than a potentially crippling server hack.

I'll be up front and say that I know little about Kerberos. What I did discover, however, is that there's a Kerberos configuration file, /Library/Preferences/edu.mit.Kerberos, that controls Kerberos behavior on a Mac client. The file didn't exist for me before I created it, but when I created it with the following contents, my connection times immediately sped up:

[libdefaults]
default_realm = foo.local
dns_fallback = no

It might be important to have a blank line at the end of this file. From what I understand, in the absence of a valid Kerberos configuration, Kerberos will do DNS lookups for configuration information by default. Since Windows doesn't respond to a Mac when it broadcasts for this information, this causes the connection to stall. The "dns_fallback = no" directive prevents the behavior. In terms of the default_realm, I don't think it matters what goes in here unless you need a valid Kerberos configuration. I apparently don't.

Feedback on this workaround would be much appreciated. It has not been widely implemented, and since I admittedly don't know much about Kerberos, it would be good for others to post warnings if I'm suggesting something awful. It has worked for me and a few colleagues, though, so I figured it would be worth putting out there.

If you can comment on this approach

DNS fallback didn't fix reader's slow SMB browsing

Friday, July 2, 2010

Dan Ball said the suggestion from earlier this week did not fix slow SMB file sharing in Snow Leopard:

Nope, this does not help with the issue. I already have DNS fallback to "no" on my OS X and it's still having the issue.

Details on DNS, kerberos, Active Directory, and slow SMB browsing

Thursday, July 8, 2010

Jelmer Jaarsma in Amsterdam found a server-side solution to slow SMB browsing in Active Directory, and commented on the article "DNS/kerberos setting workaround for slow SMB browsing:"

I would like to comment on the articles that mention switching off DNS fallback to fix slow connections to SMB. I've run into similar problems, but solved them in a different way. First of all, Kyle says that using Wireshark, he saw mDNS requests being made to the local multicast address. As far as I know that request should have been preceded by a regular DNS TXT lookup on the same record (that's what I've seen in my environment anyway). If not, have a look at http://support.apple.com/kb/HT3473 for resolving .local domains. My problem was that mounting the shares was slow, and also, a manual kinit to get a Kerberos ticket was slow (it took very long before a password prompt popped up). I also used Wireshark to troubleshoot this, and it turned out that a lookup was made for _kerberos-master._udp.domain.name.local . This is a record that Active Directory will not create on it's own, so the DNS server answered that the hostname was unknown. At that point the Mac did a fallback to mDNS and THAT is what was causing the delay. I fixed the problem by creating the record in our AD. The result was the kinit prompted for a password instantly and logging in went much faster (presumable because connecting to the cifs homedir was much faster).

So in the end I managed to fix this server side, however, as most solutions, there are ups and down sides:

  • DNS fallback still enabled on the clients, they can autoconfigure themselves
  • The _kerberos-master DNS record is not automatically created by AD so if you replace domain controllers make sure not to forget to update the record(s)!

If this helps you (or not)

TIP: Creating DNS records to fix slow SMB browsing in Active Directory

Monday, July 12, 2010

Gunno Ivansson added to the article DNS, kerberos, Active Directory, and slow SMB browsing, with a suggestion:

We had to create two DNS records to make it work, a _kerberos-master._udp.domain-name.local record, but also a _kerberos-master._tcp.domain-name.local record.

If you've tried this approach

DNS/kerberos workaround cured slow SMB for reader

Monday, August 9, 2010

Matt Horn fixed his slow SMB file sharing browsing with a recent tip about creating a kerberos file with a DNS setting. Horn reports:

I have been following the Mac SMB sharing problems for a while and found Kyle Rabe's solution to resolve the problem for me. I did a packet capture for communications between my MBP running OS X 10.6.4 64-bit and noticed the same DNS lookups for _kerberos.server.domain.local. Once I created the /Library/Preferences/edu.mit.Kerberos file my total connection time went from about 50 seconds to 5 seconds. I thought I would provide some positive feedback and thank Kyle for his suggested solution.

If you've tried this approach

TIP: Another take at adjusting DNS fallback for fixing slow SMB file sharing

Thursday, September 2, 2010

Jack Fruh had success with a previously reported tip for fixing slow SMB file sharing in Snow Leopard, and shared an alternative method:

Just wanted to say I tried the tip "DNS/Kerberos Setting workaround for slow SMB browsing." Like another reader, it cut approx 25 seconds off my time. (In my case, the delay is easy to measure repeatedly, as I have an Applescript that mounts the disk, so I don't have to type anything in.) Previous to this, it took 30 seconds from connect to 'login prompt', now it takes about 6. I did not have to reboot after creating the file /Library/Preferences/edu.mit.Kerberos

It may help others to note, if you open Terminal, and do cd /Lib(tab)/Pref(tab) you will end up on Preference (missing an S) you want Preferences. Then create the file edu.mit.Kerberos. I used the touch command to create it, then edited in NANO, easy for beginners:

touch edu.mit.Kerberos
nano edu(tab) (the tab autocompletes)

I would love to knock off the last 5 seconds of this connection delay!

If this works Note also that if you go to the original suggestion and scroll down, you find a number of other variations of the procedure.

TIP: Slow Mac SMB browsing caused by DNS records for deceased domain controller

Tuesday, January 3, 2012

Gary James responded to the report "DNS/kerberos setting workaround for slow SMB browsing" with a DNS solution of his own for slow SMB browsing. After some detective work, he found DNS servers in his Active Directory network pointing to a domain controller server that no longer existed:

Having tried Kyle Rabe's tip and Ricardo's tip and hours of digging through /var/log, and numerous other things, I figured out why our SMB browsing was so slow. When I went to go look at our new Active Directory controller and DNS server for the DNS entries in DNS that Jelmer Jaarsma mentioned I found references to our old ill-fated AD SBS server.

We had an SBS server but it was failing and we created another AD controller/DNS server. I was able to get files, DNS, AD replicated, but before we could to FSMO transfers our SBS server died, never to boot again. I cleaned up AD using every MS article that I could but there was one thing I missed, DNS still had references to the old dead server. Once I went through the whole AD DNS structure and removed/updated about 10-15 references to the old server, I killed (hup-ed) the mDNSResponder process and life was good! Specifically I think that the _msdcs NS record change was the main change needed but if you find yourself in a similar situation, you should remove/update all references in DNS for a dead, never-to-return DC. The commands I used at the terminal prompt were as follows:

ps -ax

Use this to identify the mDNSResponder process id

sudo kill -hup <PID>

Replace <PID> with the actual corresponding process id.

Hope this helps someone else. I know I am glad to be rid of this problem!

If you've seen this

Reader confirms, DNS for old server slows Mac SMB browsing

Thursday, January 19, 2012

Brendan McKitrick in London wrote responded to a recent tip about old coman name service (DNS) records slowing SMB file browsing in Mac OS X:

Regarding Gary James' report and fix here [TIP: Slow Mac SMB browsing caused by DNS records for deceased domain controller].

That was EXACTLY the issue with our domain ; our IT provider forgot to remove the DNS reference for our old, decommissioned AD server. Once all references were removed, Mac SMB browsing has dramatically improved. Very happy to have found his tip and have this resolved!

If this fix worked for you

More slow SMB file sharing linked to Active Directory, and more on DNS

Monday, October 11, 2010

Like some other readers, Tyler Ward sees a direct connection between slow SMB file sharing in Snow Leopard and Active Directory:

I have observed the issue of slow SMB mounting/browsing to be related to my workstation being joined to the AD domain. When joined, it is a rare occasion that I can connect to file shares on our server (Win 2008 Standard) in a timely manner, but when not joined to the domain, the same connection is almost instantaneous. I have tried every single suggestion I could find and found none of them to work consistently.

A change in DNS has helped some readers, though not everyone. Another take on the DNS, posted here, worked for another reader. However, Steve Cross reports that the later didn't work for him: I have tried this but no success. I may not have set it up correctly on our Windows server 2003.

If you're experiencing this

More on slow SMB browsing and DNS

Monday, May 23, 2011

Craig Miller commented on the article "DNS/kerberos setting workaround for slow SMB browsing" with some ideas:

It might not be that the DNS server doesn't respond to the mDNS, but that the network is not forwarding the multicast, you can verify this by also running a packet capture on the DNS server and see if it ever receives the mDNS request. Most networks are not configured to forward multicast past their default gateway (layer 3 boundary), but if your computer is on the same subnet as the DNS server, the switched network (layer 2) will typically forward the mDNS to all devices.

If you've seen this on your network

TIP: turn on Internet sharing as workaround for slow SMB

Monday, September 27, 2010

Jay Bradford sent in a suggestion for fixing problems with slow SMB file sharing:

I have been having the same slow connections to SMB server. I have found that enabling Internet sharing has made the SMB browsing much, much faster. This tip came from MacRumors.

If you've tried this

Reader says Internet Sharing speeds SMB

Sunday, May 15, 2011

Pedro Neto verified that turning on Internet Sharing speeds up slow SMB file sharing in Snow Leopard:

Try turning on Internet Sharing for any port; it can be Bluetooth. You can unmark the port after. This really worked for me My SMB shares are being read much faster.

Some readers have reported that this didn't work. If it works for you

Reader says Internet Sharing cuts SMB file transfer times in half

Tuesday, August 30, 2011

Philipp Jude in Germany agrees with previous posts that turning on Internet Sharing makes SMB browsing faster:

Yes, this helps a lot. I copied a 400 MB file without Internet sharing in 50 seconds. With it turned on, in 25 seconds!

If you've tried this with .

Internet sharing's effect on file transfers in Snow Leopard

Monday, September 26, 2011

Some readers have found that turning on Internet Sharing fixes Snow Leopard problems with slow SMB file sharing. But not Kevin Stauffer, who sent us some numbers:

I did a quick test involving transferring a 700 MB file from a Windows 2008 server to a Snow Leopard Mac and back again. With Internet sharing off, transfer from the server to the Mac took 1:05, and transfer back (Mac to server) took 1:32. After turning on Internet sharing, transfer from was 1:09 (+ 4 seconds) and transfer to was 1:14 (minus 18 seconds). Not a big difference either way, and perhaps could be explained by network traffic (or wind direction).

Numeric password tip confirmed for Snow Leopard SMB browsing

Monday, September 27, 2010

Alan Cruz confirmed a previously reported workaround for SMB file sharing problems in Snow Leopard:

Changing the password to numeric worked for me I think it most be some thing in the way Leopard sends the passwords to the server. Changing my /etc/hosts didn't worked at all. My SMB server is over a Solaris 10 X86.

If you've tried this

Numeric password for SMB NAS device enabled alpha password

Monday, October 4, 2010

Bill Griffin confirmed that using a numeric password allows Snow Leopard to connect to a network attached storage (NAS) device, with an odd, positive side effect:

This worked for me. I lost connections to our NAS after upgrade to Snow Leopard. We reset the password to 123 and it worked. Then, the weird thing was we changed the password back to the original and this worked too. Adding :139 did not.

Many other readers have confirmed that using a numeric password works with different types of SMB file servers. If you've tried this, does changing the password back to alphabet character now work?

All-numeric password helped user access NAS

Sunday, May 15, 2011

Kai Guse is another reader reporting success with using an all-numeric password to solve problems accessing network attached storage device. Other tips that readers have reported did not work for Guse:

Thanks for the numeric password hint. Changing the password to all-numeric helped to mount my wd-netcenter under 10.6.7. I had changed the smb.conf file, and created a sysctl.conf file as described here, with no effects.

TIP: Fix for 10.6 slow connections to SMB shares in AD: Delete SIDs

Monday, October 11, 2010

Mark Lewis reports that he discovered the cause of slow SMB file sharing with Snow Leopard on Active Directory networks. He said the cause is Security Identifiers (SIDs). Windows domain controllers assign SIDs to identify logged on users, and which are used with Access Control List (ACL) permissions. Lewis reports:

We were experiencing the SMB connection slowness described by other contributors. After working with Apple we discovered the root cause: unknown SIDs in file/folder permissions. A full description of the problem, the cause and a link to the MS tool which will cleanup the unknown SIDs can be found on our Knowledge base. Note: the issue only affects Macs that are bound to our AD.

If you've tried this approach

Deleting SIDs for slow SMB doesn't work for reader

Thursday, October 14, 2010

Dan Ball responded to this week's tip Fix for 10.6 slow connections to SMB shares in Active Directory: delete SIDs. The suggestion was that unknown Security Identifiers (SIDs) in file/folder permissions cause slow SMB access by Snow Leopard clients. However, this isn't the case for Ball, who has previously reported that another tip also didn't work. Here's his new report and observations:

Just double-checked our settings in AD and we have no unknown SIDs in our permissions so I don't think this is a full fix. Hopefully it helps someone out and appreciate the feedback from Mark, but unfortunately not the fix for here at my school.

Also I want to note there may be a couple different issues. Some people say logins to shares are slow, I am seeing no problems with that on my end. The problem we are having is browsing shares and it taking a while for things to show sometimes, even with an empty folder you can see the wheel turning at the bottom of the finder window thinking. I double checked perms and thinks are set correctly and with no unknown SIDs.

Another issue being seen is if a user is logged in and in there personal folder they create a new folder but they are unable to edit the name. They usually have to go under the folder and come back out and then are able to edit the name. Almost as if 10.6.x isn't seeing the ACLs correctly.


TIP: turn off notify in nsmb.comf for slow Snow Leopard SMB browsing

Monday, November 22, 2010

A previous contributor (who wishes to remain anonymous) sent another suggestion for slow SMB file sharing in Snow Leopard. He suggests turning off "notify" in /etc/nsmb.conf. Previously, another reader suggested editing nsmb.com to include "streams=no", a tip that had been confirmed. However, our new tip does something else :

As I said before I think we are seeing some different things happening. Some people are saying slow SMB share mounting, slow SMB browsing on shares, etc.

Personally my issue is slow browsing on the SMB shares and I may have just gotten the fix or at least a workaround. I have tested it and so far no slow browsing like I had before.

Can try adding "notify_off=yes" to the /etc/nsmb.conf file.

Or

sudo echo "[default]" > /etc/nsmb.conf
sudo echo "notify_off=yes" >> /etc/nsmb.conf

I don't know if this will help everyone or not, but hopefully it does!

If you've tried this

Note from the Editor: readers have reported that this doesn't work (or returns a"permission denied" message). We recommend using the expanded version of this tip directly below:

TIP: details on turning notify off in nsmb.conf for slow SMB browsing

Monday, December 13, 2010

A reader (name withheld by request) updated his previous tip on fixing slow SMB file sharing by turning off notify in the nsmb.conf file. Here, he provides the steps needed to do this:

To clear some things up here are step-by-step commands to run to disable notify_off in nsmb.conf file, doesn't sound like the people who responded turned the notify off:

  1. Enable "root" user and set password (In 10.6.x go under System Preferences, then under Accounts, then under Login Options to get to Open Directory Utility)
  2. Open "Terminal" and type "su root" and then type in the root credentials. Should notice command prompt change to something like "sh-3.2#".
  3. After you are logged in as root type "cd /etc"
  4. Then type: touch nsmb.conf
  5. Then Type: sudo echo "[default]" > /etc/nsmb.conf
  6. Then Type: sudo echo "notify_off=yes" >> /etc/nsmb.conf
  7. Then run "pico nsmb.conf" too view the file, should look like the following:
    [default]
    notify_off=yes
  8. Type "ctrl+x" to exit out of pico.
  9. Restart

Does this help you?

Readers: no success with notify in nsmb.conf for slow SMB browsing, but domain/username helps

Monday, November 29, 2010

Two readers tried the recent tip for fixing slow SMB file share browsing, which was to turn off notify in the nsmb.conf file. Both readers said the suggestion doesn't work. Kyle Salewski also reports that logging in with domain/username does help:

In regards to the most recent post of changing the nsmb.conf file to change slow SMB browsing: It wouldn't let me change the file as the admin, I had to use the root account. I haven't seen an improvement yet, I still need to do some more testing but I am still seeing a 2-5 second delay to have folders populate when browsing the network

I have been following the slow SMB browsing on this site for a while since my company has been experiencing issues ever since we went to Snow leopard in July. I have tried pretty much every suggestion on this site without any success sadly. Our greatest improvement was to login with DOMAIN\Username [as the user name] when mounting the share. It went from a 10-15 second delay to a 2-5 second delay when browsing folders, and it is still always intermittent.

Tim also could not use this suggestion:

I have no nsmb.conf file in /etc. I do have an smb.conf. When I try the command, I get access denied. I connect to SMB shares every day. Sometimes they are slow to display the contents.

If you've tried this

Confirmation and advice for turning off nsmb.conf for slow SMB browsing

Wednesday, December 29, 2010

Felix Aumaitre writes that the tip "Details on turning notify off in nsmb.conf for slow SMB browsing" solved the file sharing problem for him in Snow Leopard. He also added a step:

This trick works and fixes this issue for me in two iMacs with Mac OS X 10.6.5. Also, I modify the /etc/hosts file as root user and add a line with the IP and filename of my SMB server. After a reboot the iMac mounts a SMB share with as a normal way and showing the folder contents is fast as other machines in the same LAN. Thanks a lot to Macwindows.com.

If you've tried this

Note also that previously, another reader suggested editing nsmb.com to include "streams=no", a tip that has been confirmed.

More success with nsmb.conf tip for slow SMB file share browsing, and a question

Monday, January 3, 2011

Sebastian Pein had success with last week's variant of the tip to fix slow SMB file share browsing with Snow Leopard, regarding turning off notify in nsmb.conf. He also wants to know why it works:

Finally it seems there is a workaround for the slow SMB browsing issue! I want to confirm the anonymous tip that suggests creating the /etc/nsmb.conf file does the trick. Although not heavily tested, on my snow leopard testing machine (10.6.5, 32 bit mac mini 1,1) the nsmb.conf prevents me from being delayed for 15s while browsing smb shares on a 2003 machine. all the other tips did not change a thing. I have inspected everything one could imagine, from dns/mdns issues all the way to kerberos related stuff.

So this might be it, that leaves only one question open: what is the nsmb.conf all about? The MAN page is not too clear. Perhaps you can post that question in order for some guru guys to tell something about it.

Any gurus want to take a shot? If so,

How nsmb.conf, ack=0, and other tips affect slow SMB file sharing

Friday, January 7, 2011

Jonathan Agosta answered our call for an explanation of the nsmb.conf file and how it can fix slow SMB (also known as Samba) file browsing in Macs. He explained the tip about using the file to turn "notify" off, and why it might not work for all users. He also describes several other configuration tips that we've reported and thinks making these changes on a Windows Server instead of the Mac could be productive:

The nsmb.conf file contains settings (If it doesn't exist defaults are used) to configure the Network Protocol for Samba. The notify_off=yes setting will disable the Samba Notify-Change feature which is used to dynamically update the client's listing of files/folders as they are changed. (I have attached references.)

This can have a very noticeable impact on SMB file shares containing a large number of files and/or for those who have an environment where there is a lot of activity and changes made to the files. This is also why it does not affect certain users, especially those with more static content or few files. The interesting part is that searching for problems on the Microsoft site leads us to......Read entire story here

SMB vs. Samba, and what Apple uses for file sharing

Monday, January 10, 2011

A reader sent in this clarifying comment on the article "How nsmb.conf, ack=0, and other tips affect slow SMB file sharing:"

Small technical correction for you. You made the statement "SMB (also known as Samba)". SMB, SMB-2, CIFS are protocol names and Samba, like Thursby's DAVE, are product implementation names. Apple currently uses Samba technology only for the server side while the client, which is the most commonly customer used code, is actually based on FreeBSD client code by Boris Popov.

TIP: New Finder-based workaround for slow SMB file sharing: turn off display of server in sidebar

Wednesday, January 26, 2011

Christopher Roehl shared his workaround for the problem of slow SMB file sharing in Snow Leopard. We've had many suggestions for working around this problem, including this one. Here's Roehl's report:

I've been following the issue of slow server browsing in Mac OS X 10.6.x and can continue to say that in 10.6.6 it is still a problem, I'm connecting to a fileserver running Windows Server 2003 R2, and upon initial login, it is fast, but as soon as you go to another volume and come back, it takes sometimes up to a minute for the folders to appear again. I've also found that after initial login to the server, if I disconnect and try to reconnect it will take a long time. In contrast to 10.5.8 where it may take a while to make initial login, it continues to be very fast in the Finder no matter how many times you come back to it. I have different Windows Server environments in different locations I support and this behavior is consistent in all locations.

I think I have come up with a workaround for my situation. In the Finder Preferences I go to the "Sidebar", and uncheck "Connected servers" under the "Shared" heading. Still within Finder Preferences under "General" I check "Connected servers."

This shows only the volume I have mounted instead of the whole server, these settings also carry into the open dialog boxes within applications. I can browse away from the connection and connect to the share and it displays everything quickly. (Personally, this is how I prefer to see the servers anyhow.)

If you've tried this approach

Reader confirms Finder-based solution for slow SMB browsing (turning of display of server in Sidebar)

Monday, February 21, 2011

Pavel Holik confirmed the suggestion "TIP: New Finder-based workaround for slow SMB file sharing," where some changes to Finder settings fixes Snow Leopard problems with slow SMB file sharing:

This tip works perfectly for me. It made a huge difference in browsing and opening files.

If you've tried this suggestion

Reader confirms turning off server display in sidebar speeds SMB file sharing

Monday, March 21, 2011

Walter Koerber confirmed a Finder-based workaround to solve Snow Leopard's slow SMB file sharing problems. The tip is in Finder Preferences, to turn-off display of connected servers in the sidebar, and turn it on in the desktop. Koerber reports:

Just tried this tip and I can confirm this speeds up file browsing.

If you've tried this approach

Reader confirms turning off Finder server display speeds SMB

Tuesday, April 13, 2011

Rich Rodecker confirmed the suggestion that a Finder tweak speeds up SMB file sharing in Mac OS X:

Just wanted to let you know that the tip "New Finder-based workaround for slow SMB file sharing: turn off display of server in sidebar" worked perfectly for me. Finder browsing of SMB shares is dramatically faster.

If you've tried this

Reader confirms turning off Finder server display fixes slow SMB

Monday, May 2, 2011

Jessica McFarland confirmed that turning off the display of connected servers in the Finder can fix Snow Leopard problems with SMB file sharing?

It works! It Works! It Works! Not only With Windows Server 2003, but Windows Server 2008 R2 and Windows Storage Server 2008! Thank you!

If you've tried this fix

TIP: Fixing slow SMB file sharing by turning off NetBIOS queries

Tuesday, September 6, 2011

Scott Stansbury shared the results of his research on the problem of slow Snow Leopard SMB browsing and file sharing. He looked at various edits to the /etc/nsmb.conf and /etc/smb.conf files, some that we've reported before on the Snow Leopard Tips and Reports page, and some that he figured out himself. The tips reported here helped with slow browsing (this previous report sums it up), but he fixed slow file connection times by editing /etc/nsmb.conf to stop NetBIOS queries, using the line port445=no_netbios. Stansbury's report......Read entire story here

TIP: For slow SMB browsing, edit nsmb.conf in Library folder

Tuesday, October 4, 2011

Rob Calhoun found success with the procedure in "Fixing slow SMB file sharing by turning off NetBIOS queries," but he recommends editing a different nsmb.conf file than the one suggested:

I just tried this hint.

Following the man page, I created and edited ~/Library/Preferences/nsmb.conf rather than /etc/nsmb.conf . This is safer than working in /etc and I'm the only user anyway. It works! But, with no notifications, it seemed like there is a bit of a delay......Read entire story here

TIP: fix for slow Mac OS X 10.6 SMB browsing of shares

Monday, November 7, 2011

Nathan Friedl combined two previously reported tips to fix slow SMB file share browsing in Snow Leopard.

I just wanted to let you know that we've just had success resolving our issues with some of our 10.6 Macs and slow samba speeds. By combining the nsmb.conf and sysctl.conf tweaks, we have dramatically improved browsing speeds on the Macs that were experiencing these problems.

If you've tried this approach

Related stories about slow Snow Leopard SMB filesharing: How nsmb.conf and other tips affects slow SMB file sharing and TIP: Fixing slow SMB file sharing by turning off NetBIOS queries.


Reader says slow SMB file browsing started with Win 2008

Tuesday, May 18, 2010

George Markides says his slow file browsing problems started only with Windows Server 2008:

Ever since my school board went to Windows Server 2008 our Macintosh machines take a VERY long time (3-5 minutes) to display the contents of shared folders on the server. When the school board was running Server 2003 the Macintoshes were loading up folders as fast as the PCs. We have not found a work-around yet.

If you've seen a change in Windows Server slow down file browsing

We've been posting reports of slow Snow Leopard SMB file sharing for user connecting not only Windows servers, but with Linux servers and network attached storage. (See Snow Leopard File Sharing Tips and Reports.)

Another reader says Win Server 2008 linked to slow SMB with Snow Leopard

Tuesday, May 25, 2010

Olivier Jaillet in Switzerland agreed with last week's report, Reader says slow SMB file browsing started with Win 2008:

I read your post about slow connections to mount SMB shares from a Windows Small Business Server 2008 with a MBP OS X 10.6. We have another Windows Server with 2003 and it goes much faster. I think the problem is on the configuration of the SBS 2008.

If you've seen this


Reader says new Finder 10.6.5 fixes slow SMB browsing | Top of Page |

Thursday, May 13, 2010

Asger Jensen in Europe reports that he received a brand new MacBook Pro installed with Finder version 10.6.5. His other Snow Leopard Macs have Finder 10.6.4. More significantly, Finder 10.6.5 doesn't have the Snow Leopard problems of slow SMB file share browsing:

Until now I have tried all suggestions on your site to fix the dreaded problem with browsing SMB-shares from 10.6.1-through-10.6.3 with no luck. But today, browsing the exact same shares from my new MacBook Pro 15" 2010 model I experience no sudden pauses in directory listing.

It seems though that Apple has fixed the problem in a new build of the Finder.app. On my machine with the shipped OS X10.6.3, Finder.app is version 10.6.5, but on the Company's Mac Pro with retail OSX 10.6.3 the Finder.app is 10.6.4. So hopefully OS X 10.6.4 will include Finder.app 10.6.5.

If you've seen Finder 10.6.5 on your new Mac if it fixes this issue.

More on Finder 10.6.5 and slow SMB access

Tuesday, May 18, 2010

An anonymous reader told us "The 10.6.5 Finder DOES NOT fix it for me!" in response to last week's report regarding a new version 10.6.5 of the Finder that was reported to fix Snow Leopard's problem of slow SMB browsing. Rodrigo Perez tried a different approach -- a drag-and-drop copy of the new Finder (which is located in the folder /System/Library/CoreServices/) to his Mac. It didn't work. However, Perez reported some interesting information:

I read the post yesterday regarding "Reader says new Finder 10.6.5 fixes slow SMB browsing," so I stopped by the local Apple store last night and copied the 10.6.5 Finder onto a flash drive. I installed it this morning to give it a try; however, it did not fix the slow browsing problem on my MacBook Pro. It would appear that there are some other updates that may be necessary to address the issue.

I have also worked with AppleCare to try and resolve the SMB access delay, but we were not able to do so. They claimed no knowledge of the issue and said that they had thousands of installations in Active Directory environments without any problems, which is likely the case. It's just a few of us having this issue. At any rate, the only other option that they could offer was to escalate the problem to Engineering for a charge of $695.00. It is a real nuisance, but not worth that investment, I'm afraid.

I sure hope that Apple does come out with a fix soon as this is an annoying issue that causes daily irritation.

If you've seen Finder 10.6.5 and can comment on its effect on the slow file sharing issue

Does Mac OS X 10.6.3 Build 10D2094 fix slow SMB?

Friday, May 21, 2010

Asger Jensen followed up on his previous report about a new Finder 10.6.5 build not having the slow SMB browsing problems. He now thinks that the problem is resolved not just with the new Finder, but a new build to Mac OS X 10.6.3 -- Build 10D2094-- that is showing up on some new Macs:

I have made a few more observations that might be of interest to you and all the others who struggle with this very annoying issue. First I will be using OS X build numbers:

Macbook Pro 15" 2.4 Core2Duo 2008 retail OSX 10.6.3: Build 10D*573*
Macbook Pro 15" 2.4 Core i5 2010 preinstalled OSX 10.6.3: Build 10D*2094*

Having now browsed literally hundreds of folders with no problems on 2094 compared to frequent pauses (every 20 or so folders opened) on 573 I feel confident that the issue has been fixed in build 2094.

It seems though that it is not the Finder.app itlsef that fixes the issue. For the fun of it I copied the new Finder to from 2094 to 573 and it is actually working (so far) but I am still experiencing the pauses in SMB directory listing. Apparently the new Finder version is only an indication of some more "under the hood" changes of supporting files/processes which actually addresses the issue.

A funny thing is, that when running normally, 573 is a bit faster than 2094 at showing folder content. I am testing the two machines side by side browsing in column view hitting the arrow keys simultaneously (all view settings identical). In my opinion a minor trade off compared to stability.

If you've seen this

Slow SMB file sharing not fixed with OS X 10.6.4/Finder 10.6.5

Friday, June 18, 2010

Although readers have previously reported that slow SMB file sharing cleared up with a new version of the Finder, readers today said that that the Finder in the new Mac OS X 10.6.4 does not fix the problem. Marius de Reus in Holland reports:

We are also struggling with slow browsing from Mac to our Win 2008 SBS server. The new Snow Leopard 10.6.4 (with Finder 10.6.5) doesn't fix the speed problems for us. Opening folders on the server can still easily last about 15 seconds, while there are only 12 files in the folder. I also tried the terminal tcp.delayed setting with no luck. This is very annoying!

Lee Campbell said the same:

Mac OS X 10.6.3 Build 10D2094 does not fix slow SMB. Nor does 10.6.4 update to Snow Leopard, which does claim to fix issues with samba file sharing. It seems that this update doesnt' fix the problem. I'm on an April 2010 Macbook Pro.

TIP: fixes for slow SMB: use FQDN, and confirmation of turn off notify

Thursday, March 3, 2011

Two readers wrote in to confirm that turning off notify off in the file nsmb.conf cleared up slow SMB file sharing in Snow Leopard. First, Rodrigo Perez reported this as well as some other observations with two other tips. He also discovered something new, that using a fully qualified domain name (FQDN) to log on cleared up the problem. Perez' report:

Finally, at long last I have been able to fix the slow SMB access for our two Macs here at work thanks to your website! I've been reading the site regularly and on the occasional Friday afternoon would spend a few minutes troubleshooting to see if I could come up with anything. The week before last I hit pay dirt and things have been working well ever since. Here's what I found:

I applied the 'sysctl -w net.inet.tcp.delayed_ack=0' tip quite some time ago and it helped to reduce some of the wait times when accessing Windows server shares over SMB, so I've kept that in place. Even with this fix, I still always had delays when accessing the actual shares at the server-level of about 15-20 seconds, then seemingly random 20-30 second delays when accessing various subdirectories within the shares. Sometimes a directory would open quickly, other times it would experience the delay with no rhyme or reason as to when it would occur.

Next, I applied the 'turn off notify in nsmb.conf' tip and, voila!, the delays when browsing subdirectories disappeared. This was exciting stuff, indeed, but it still left me with the slow access at the server-level shares. I then remembered the tip 'Login with port 139 to access SMB shares with Snow Leopard' and tried that. Again, I met with success and now the delay at the server-level shares was gone! I've been on cloud nine ever since!

I did do a bit more experimenting with the port 139 fix and found that I didn't actually need to specify the port in the Finder's Go, Connect to Server dialog, but what actually resolved the server-level share access delay was using the fully qualified domain name (FQDN) of the server instead of just the server's name. In other words, instead of simply connecting to SMB://ServerName, I now use SMB://ServerName.DomainName.local and everything works pretty much instantaneously, just as it used to in OS X 10.5 Leopard.

Perhaps the combination of these fixes will work for someone else as well. At least I'm two for two.

If you've tried logging on using the FQDN to prevent slow SMB file sharing

Kyle Salewski also reports success with the turning off notify:

I reported back in November that turning notify off in nsmb.conf did not show any improvement in initial testing on our test iMac running 10.6.4. I have recently made this change on an iMac running 10.6.4 in our production environment and the user is reporting a dramatic speed increase when browsing for files just after one day! It doesn't populate the folder contents instantly yet (1-2s delay still), but has been a huge improvement from where they were previously.

Is FQDN and turning off Notify the "final answer" for SMB problem?

Wednesday, March 9, 2011

Tom Waterhouse confirmed last week's report that a combination of two suggestions fixes problems with slow SMB file sharing browsing in Snow Leopard. Waterhouse said:

Just to add my voice to saga of slow finder browsing, I have tried previous fixes and found nothing worked consistently, but so far using both FQDN and turning notification off seems to do the trick! I've been happily using the Finder problem free for the past 2 days since I applied this fix. Normally I would experience the problems pretty early in the day, but it's been 100% successful so far. Many thanks for the tip!

If you tried this approach

Reader confirms using FQDN and turning off Notify solves slow SMB problem

Monday, March 14, 2011

Canadian reader Brad Anderson responded positively to last week's article "Is FQDN and turning off Notify the 'final answer' for SMB problem?" for Mac Snow Leopard clients. FQDN is the fully qualified domain name, which he describes:

I made the same change (turn notify off) and started using the FQDN to connect to all my SMB shares (smb://server.mydomain.local) and the speed has drastically increased. Everything from connecting to a share to navigating the folders within is almost instant compared to what it used to be on my Snow Leopard machine.

For Sonja Kirsch in Germany, turning off Notify was enough:

I tried the "tip" at your Web site (TIP: details on turning notify off in nsmb.conf for slow SMB browsing, dated Monday, December 13, 2010) and now it works! SMB browsing is now faster.

If this finally fixes the slow SMB file sharing problem for you

Reader says SMB still slow in 10.6.7; Finder, Notify tips don't work.

Friday, April 8, 2011

Gabor Hollai reports that the latest Mac OS X 10.6.7 update from Apple does not fix his problem with slow SMB file sharing. He also notes that the tip Finder preferences modification, notify_off=yes, also does not work for him. (This procedure has worked for several readers.) Hollai reports:

We have Win2008R2 Standard server and we would like to connect from Mac (10.6.7) via SMB. I have read your article and I have do what you have suggested (Finder preferences modification, notify_off=yes), but unfortunately the SMB is still slow. It is need about 4-5 minutes to just browse into the share. This server is virtual and I also have tried to connect a physical server and same problem.

Has Mac OS X 10.6.7 fixed any filesharing or other problems for you? Also, the article 'Is FQDN and turning off Notify the "final answer" for SMB problem?' seems to help some readers. If it helps you

Current news on the MacWindows home page

Snow Leopard Server for Dummies
By John Rizzo

A 432-page book that simplifies the installation, configuration, and management of Apple's Mac OS X 10.6 Server software. Support Mac and Windows clients for file sharing, email, and directory services; Incorporate a Mac subnet into a Windows Active Directory domain, manage Mac and Windows clients, and configure security options, and more. Click here for more.


Reader's Snow Leopard blocks networking connections | Top of Page |

Monday, September 21, 2009

Ethernet connections sometimes stop working on John Wiegley's Snow Leopard-installed Mac, particularly when he is using network attached storage:

I'm also having issues with my NAS and Snow Leopard. The problem from me -- both from a Mac Pro and a MacBook Pro, both running 10.6.1 -- is that Ethernet will inexplicably stop working at random times. When it does, any attempt to use networking in any way, whether ping or running netstat, will completely lock that process until I reset the machine. I can still use the machine in every other way, but of course the NAS and the Internet are locked out. I'm not sure if this is network AFP related or not, but I only notice it happening when I'm using the NAS constantly.

If you've seen this

TIPS: Reports of .DS_Store role in Snow Leopard Mac OS X 10.6 SMB file sharing and NAS problems | Top of Page |

Wednesday, September 23, 2009

Two readers reported that .DS_Store files on SMB volumes play a role in the file sharing. However, while one reader said that eliminating the files fixed his problem with network attached storage (NAS), another report that hiding the files CAUSED the problem of Snow Leopard access to a Linux SMB server. Marco Pistolesi fixed his problem with Snow Leopard accessing NAS via SMB. He was seeing the Finder stop responding in subfolders. His suggestion:

I've got a walkaround: just delete all the .DS_Store files and all the hidden "._filename" files from all the directories and the SMB share on the NAS device will be perfectly available.

If you've tried this This only applies to SMB, but readers have also reported problems with Mac OS X 10.6 and AFP access to NAS.

David Guerin's Linux server was set to hide .DS_Store files. When he removed the setting, the Snow Leopard's SMB problems disappeared:

I was having trouble also, when using Snow Leopard to connect to a samba server running Ubuntu 8.10 Intrepid Ibex. When I had Leopard the server would fine, no issues at all. But when I moved to Snow Leopard I did not have issues initially but after my username and password have been added to the Snow Leopard Keychain, then the issues started to pop up.

I could connect to any SMB share on the server fine, but the folders inside that share to not open and do no show the files therein. I just get the Finder spinning wheel, that never stops spinning on the bottom right in the same window. I do not have a DNS set up, so I just connect via the ip address of server and the name of the share. i.e. "smb://192.168.2.1/storage"

I checked into this further, but it was not the keychain as I first thought but rather how I had hid the .DS_Store files on the Linux box so that Windows could not see them when the "View hidden files and folder" option was turned on.

I was using the "veto files = /.DS_Store/" configuration in my smb.conf file to hide the file. As a result when ever I connected to the share on Snow Leopard I got the "Spinning Wheel" on the bottom right of the Finder Window, that just never stopped spinning.

When I commented this config line out and restarted Samba, all was well. There must be a greater need for this .DS_Store file in Snow Leopard than there is for Leopard.

At the moment I do not have the .DS_Store files "hidden" on the samba share; the downside is that Windows computers can see them.

If you've tried this

Another reader deletes .DS_store fixes slow NAS access

Wednesday, October 21, 2009

Tom Foth confirmed this workaround for Snow Leopard problems with slow network attached storage access:

SMB access to an Linksys Unslung NSLU2 NAS was incredibly slow with Snow Leopard. I deleted all of the .DS_Store files and the slowness went away.

If you've tried this


Finder locks up when browsing SMB shares on a Windows domain, and workaround | Top of Page |

Wednesday, September 23, 2009

Flemming Jønsson is seeing the Finder lock up with SMB shares, but only in a Windows domain. He also has a workaround:

At my workplace we have a Windows file server connected to a Windows domain. In 10.5.8 I had no problems connecting to and using this share, but after upgrading to 10.6 and later 10.6.1 I can only connect to the share, not browse the share using Finder. If I try Finder will hang. If I want to restart OSX I have to kill/relaunch finder before restart is even possible.

However if I use muCommander, or the command line to mount the share, I don't have any problems. I would still like to know how to make Finder work with shares on a windows domain, but for now I'm switching to using muCommander whenever I work on Windows domain shares.

At home on my personal NAS I do not have any problems with my SMB shares and Finder in 10.6.x, it is only a problem for me when there is a Windows domain involved.

If you've seen this

Reader confirms utility workaround to problems accessing NAS

Monday, May 23, 2011

Julien Schulz verified the tip about using MuCommander to get around problems accessing a network attached storage (NAS) device with Snow Leopard:

My D-Link DNS-323 NAS was working perfectly on my 2 previous laptop on Mac OS X 10.4.11 and 10.5.8. I just bought a new MacBook Pro on Mac OS X 10.6.7; and although I can see my NAS and the volumes, I could not access to it: wrong password or username. Oddly enough, I could access to the webpage volume that open the config page of the NAS.

The freeware MuCommander found on one of the tips from your website made my NAS accessible again, not a real fix, but at least a temporarely solution.

If you've tried MuCommander as a workaround for this problem .


TIP: SMB wrong password error due to special character user name | Top of Page |

Tuesday, November 3, 2009

Jorgen Kirkovits discovered that using an umlauted character in an SMB user name gave him a "wrong password" error in Snow Leopard. Removing the character fixed it:

I had a problem with connection to shared directories from my Snow Leopard MacBook to a Windows 7 PC as well. I recently re-installed my HTPC ("updated" from Win 7 RC to final), but chose a different username (Jürgen instead of JK). I started getting a "password incorrect" error when trying to connect to my shares (which worked with Snow Leopard before the new Win 7 installation).

I just then a new account named 'JK' and it works! So I can definitely confirm that Snow Leopard has issues connection to SMB-shares with special characters in the user name. Hope that Apple fixes that soon!

If you've seen this

TIP: Workaround for Snow Leopard SMB incorrect password error

Thursday, January 28, 2010

Kris Robison sent us his solution to an "incorrect password" error in Snow Leopard when trying to connect to his Linux SMB server:

Trying to connect to Linux via Finder was giving us the "Incorrect username/password" error. Our final solution involved going into the server's /etc/samba/smb.conf file and setting "encrypt passwords = yes" for the server. Restarted samba on the server, and Finder immediately started working again.

If you've tried this suggestion


Problem printing from Win to a Snow Leopard Mac-connected printer | Top of Page |

Wednesday, November 4, 2009

Readers have previously reported problems printing from Snow Leopard to Windows-connected printers, but Mausy's problem is the other way around:

Have an iMac (early 2008) with an Epson DX7450 connected via USB. This printer is being shared across the network. Earlier this week this set-up worked fine. I could print from my Windows XP SP3 PC to the Epson printer without any problems. However, things changed after installing Snow Leopard (10.6.1). Now, when I print from the Windows PC I get a print-out of the page; BUT the print-out is reduced in size and centered on the page.

I believe my problem is Snow leopard related, as I've not changed anything on the Windows box. I had the same problem also on virtual machines running locally. I've solved that by configuring the VM to show the USB-port to the virtual OS. Then I just installed the printer's driver in Win XP on the virtual machine. It detected the printer and that's working fine now. Of course, that is not an option when I'm connecting across the network to my Mac.

I've looked at the printer's settings on the Windows machine. The printer is set-up to print to http://AlphaMac.local:631/printers/<printername>

I've tested with the print processor set to RAW, NT EMF 1.008 and TEXT. The first two gave similar results, the latter doesn't work at all (as expected).

On the Mac side I get messages in the log from the firewall when I'm printing from the Windows-box: Firewall[60] Allow cupsd connecting from 10.0.1.4:1153 to port 631 proto=6 Firewall[60] Allow smbd connecting from 10.0.1.4:1155 to port 139 proto=6

So, that's where I'm stuck.

The Windows XP SP3 computer has Bonjour installed. I've configured a printer driver through Bonjour to my Epson DX7450 (that uses the driver for HP Color LJ 4550 PS). I've also configured a printer-driver directly as a network printer also to the same Epson DX7450. However, here I'm using a slightly different driver: HP Color LJ 8500 PS.

Printing to the Epson from within OS X with the Epson drivers supplied by Apple seems to be working fine.

If you have a suggestion


10.6.2 fixes reader's problems with Win Server browsing and access | Top of Page |

Wednesday, November 11, 2009

Dieter Schüle reported that installing the Snow Leopard 10.6.2 update fixed his problems with browsing and accessing Windows servers:

I would like to tell you my experiences with Mac OS 10.6/10.6.1 and 10.6.2 and network shares from Windows Server 2003/Windows Server 2008/Windows 7.

  1. With 10.5, there have not been any issues accessing file shares from Windows Server 2003/2008/Windows 7.
  2. With 10.6/10.6.1, connecting to the file shares on Windows Server 2003 and Windows 7 was not longer possible, while connecting to the Windows Server 2003 share still worked. Additionally, none of the Windows machines have been visible in Finder. Adding port 139 (:139) did at least let me connect to the files shares using the Finder.
  3. Today, I installed 10.6.2 and I am quite happy. The Windows machines are visible and browsable in the Finder again and I can access the file shares on each of the mentioned Windows machines without the port 139 workaround.

If you've installed 10.6.2 how it affected these file sharing problems.

Using Terminal to get around Snow Leopard file sharing issues

Monday, November 23, 2009

Although one reader previously reported that the 10.6.2 update fixed his problems with file sharing, Stephen Graham still has the problem. His workaround is to use the command line in Terminal:

I've only ever used OS X on and off over the years so I'm no expert in these things, but I've found the attempting to connect to a Windows/Linux SMB share from the Finder 'Connect to Server' dialog doesn't work. I have tried all of the solutions offered here, but none have worked for me.

However, I have found that I can connect if I setup the connection via the command line.

Assuming that your local account name (on OS X) is the same as the account name on the SMB share that you're connecting to the following will work.

mount -t smbfs //<server-name-or-ip>/<share-name> /Volumes/<mount-point>

You will be prompted for your password.

You will then hopefully be connected to the share. However, the share doesn't show up in the Finder, so it can only be used from the command line. I'm wondering if there are any OS X users who know how to complete this solution. In any case, this might show that the problem exists in the Finder rather than in the underlying Samba code.

TIP: Microsoft security patch fixes Mac file browsing issue with Vista, Server | Top of Page |

Monday, December 21, 2009

A Microsoft security update for Windows 7 and Vista and Windows Server 2008 enables Mac OS X to browse for file shares on those systems, according to a reader. Peter Goddard reports that the security patch turns off SMB 2.0, enabling Mac OS X from Tiger to Snow Leopard to browse. An ArsTechnica article describes the patch in terms of plugging a security hole, but Goddard said it fixed file sharing browser on all his Macs:

I have not been able to browse network shares in mixed Vista/OS X 10.4-through-10.6.2 networks. They are accessible by go->smb://[share_ip_or_name] no problem but they never show in the Finder sidebar until after I_ve used go->

I have been studying this problem for months with no success until today. Following the instructions in the linked article I was able to download a Windows quick-fix that disabled SMB 2.0 and bingo. All the shares on my Windows 7 machine are visible. As I applied the fix to each Vista machine on my VPN, they all appeared with all their shares when I click on "All", under Shares in the sidebar. This is a solid fix for me. I hope it helps someone.

If you've tried this approach

Alternative view on Snow Leopard SMB file browsing tip

Wednesday, December 23, 2009

Peter Kloss questioned Monday's suggestion for fixing Snow Leopard file browsing problems with SMB servers. The suggestion was to use a Microsoft patch that disabled SMB 2.0. Kloss doesn't like this approach:

I have serious concerns about the logic and quality of the suggested fix "Microsoft security patch fixes Mac file browsing issue with Vista, Server." The problems with this are:

  1. This is not a 'patch' at all - just a 'switch' for conveniently disabling and enabling SMB 2 to temporarily disable it.
  2. The 'patch' is old from September, and MS issued a proper fix which allows SMB 2 to work properly in October, MS 09-050. So if a sysadmin used the 'patch' to turn off SMB 2 it would only have been temporary and it would in the normal course of things be back.
  3. SMB 2 is version 2 for a reason - it is more secure in normal circumstances than v 1 and so from a Windows admin point of view would be enabled out of choice. Asking a Windows admin to turn off SMB 2 just so your Mac can connect is not going to earn any favours!
  4. The proper fix is for Apple to tune their SMB client to work properly with SMB 2 - raise a bug report! There still many issues around Windows connectivity that are still not fixed in 10.6.2 and we want them to be fixed in 10.6.3 (try 'AD and portable accounts' for one!)

If you'd like to join the debate

Snow Leopard timestamp change on Office files | Top of Page |

Monday, February 8, 2010

Troy Hunter is seeing a problem where the modification dates of Office files change when files are opened on a Windows server:

When connected to Windows Server 2003 shares via SMB, our fully updated 10.6 machines exhibit wonkiness. If you open anything that can be opened in Office 2008 (Powerpoint, Excel, Word) and immediately close it, the "Date Modified" changes, even if no changes were made. Simply opening the document changes its modification date, something that can drive someone whose job it is to do version tracking absolutely insane. This does not happen for TextEdit.

If you've seen this problem

Another report of timestamp change on Office files

Wednesday, February 24, 2010

John Lockwood in the United Kingdom verified a problem where the modification dates of Office files change when files are opened on a Windows server. The original report was with Snow Leoaprd. However, Lockwood sees this with Tiger:

I have seen this problem with Mac OS X 10.4 and later clients, with Office files (both Word and Excel) on a Mac OS X 10.4 and later server. This was with Office 2004 for Mac. It seems that Office 2004 11.5.6, with Mac OS X 10.6.2 client and Mac OS X 10.6.2 Server might not do this anymore, but a Mac OS X 10.4.11 client does.

Office file date modified changes when files opened server

Tuesday, May 25, 2010

Chaithanya Ravipati in Australia reports having the problem of modification dates of Office files changing when files are opened on a Windows server:

We have Mac OS X Server 10.6.3 with Mac OS X 10.6.3 clients using Office 2004 and Office 2008. As soon as you open the Office documents, the date modified changes, even if you haven't made any changes to the document.

If you've seen this problem


TIP: Fix for Mac OS X connecting to Win XP as a non-guest | Top of Page |

Saturday, March 13, 2010

Darrin Jackson had a problem where Macs on his network could connect to a Windows XP as guests for file sharing. All computers were on an AirPort network. His fix involves unchecking "Use simple file sharing" in Windows, among other things:

I was having trouble connecting my Windows XP PC to my Mac OS network (I'm using Leopard 10.5.8 and Snow Leopard). I searched the web, your site came up, but nothing worked. I googled to my fingers got sore.

My Mac would only allow me to connect to my PC as guest. No matter how many times I've changed the username. I even tried the all-numeric password tip and the port 139 tip with no success. But the solution was actually simple......Read full story here

Reader says 10.6.3 broke SMB file sharing, -36 errors | Top of Page |

Friday, April 2, 2010

Although the Snow Leopard 10.6.3 update fixed some SMB file sharing issues, Glenn Mealey say it caused a new problem:

Since upgrading to 10.6.3 I can no longer write files to my windows server. It gives me permission errors, -36. I can transfer the files using RDC with no permission problems. It was working fine till I upgraded yesterday.

If you've seen 10.6.3 update causing file sharing problems

Reader says Mac OS X 10.6.3 update doesn't fix SMB browsing problem | Top of Page |

Friday, April 2, 2010

Helge Rebhan reports that the Snow Leopard 10.6.3 update doesn't fix problems accessing SMB file services. A reported workaround, using an all-numeric password, still works for him:

Unfortunately I got to report that the issue with "numeric passwords only" was not resolved with my setup in 10.6.3. I am connecting to a Linux Samba share and the "NetAuthAgend" process always reports a "wrong password" error. As with 10.6.2 the problem disappears with a numerical password, but I don't like this work-around. Setup: MacPro (2008 Model) with 10.6.3.

Suggestions and more reports of 10.6.3 causing -36 errors with SMB file sharing

Wednesday, April 7, 2010

A number of readers confirmed Monday's report of the Mac OS X 10.6.3 update causing (and not fixing) -36 errors with SMB file sharing. Rafael Toledo said that the suggestion of adding "streams=no" to the /etc/nsmb.conf file on the Mac fixes the problem in any Snow Leopard build:

This definitely works. We were going crazy trying to find out why the files were showing grey out on 10.6.1/2/3. This fixed the problem. Did not have to reboot.

Alex Bijamov said a previously reported fix for network attached storage (NAS) devices (adding "unix extensions = no" to the /etc/smb.config on the NAS device) still works for 10.6.3:

Just letting know that I've experience same issue. The fix that worked is this one.

Matt Plessinger said the update caused the problem accessing Windows 7:

I've had this problem since 10.6.3 as well. I can no longer write files from my iMac to my Sony PC running Windows 7. The keep getting the -36 errors as well.

Johannes has the problem with an SMB NAS device, but only from the Finder:

I am still getting the -36 error when trying to copy single files to a SMB share. I still have the problem with Mac OS 10.6.3 However, I can successfully copy the files using Terminal. This is a home network and there are no logon or passwords needed. It is a Vantec network drive NexStarLX. Currenlty, it's working fine with other Linux and Windows machines.

If you've tried these suggestions

"Unix extensions = no" fixes SMB -36 errors, but slows service

Tuesday, June 22, 2010

Like some other readers, Christopher Hearn confirmed that adding "unix extensions = no" to a Linux server's smb.conf file stopped Mac SMB file sharing clients from getting -36 errors. However, it came at a price:

While I can verify this does work, it also severely hinders SMB performance. With the option disabled, I would get ~50MB/s using SMB with OS X clients to OS X Server. With the option enabled, throughput dropped to ~5MB/s.

If you've seen this


Reader says 10.6.3 update breaks AFP file sharing | Top of Page |

Wednesday, April 7, 2010

Wissam Abulhuda reports that the Mac OS X 10.6.3 update causes several problems with AFP file sharing:

I have been experiencing many issues since updating my Mac OS X installation with 10.6.3.

  • AFP shares are no longer visible. No issues with SMB/CIFS shares.
  • Bonjour/mDNSResponder is not locating printers/afp shares etc...
  • Loading System Preferences/Sharing causes Bluetooth and other core components to crash ie. The Finder crashes and shares are dropped, rendering the machine unresponsive.

I wish Apple would stop releasing updates for their customers/users to test.

If you've seen this problem

TIP: repair permissions for 10.6.3 printing and AFP problems

Tuesday, April 20, 2010

Matty Lynch confirmed previously problems with the Mac OS X 10.6.3 update causing problems with printing and problems accessing AFP file servers. However, simply repairing permissions cleared it all up for him:

I was having the same problem you reported with both issues of printers and a local AFP server. I added printers by IP and still no luck. I could not connect to OS X Snow Leopard Server via AFP ever since the 10.6.3 upgrade. When I restarted there was 2 GB of temp files in the trash that weren't there before the restart.

But I used Disk Utility to repair permissions, and the problem with both AFP and printing is now resolved.

If you've tried repairing permission to resolve these problems with 10.6.3

More reports of 10.6.3 AFP file sharing problems, Finder crashes

Thursday, April 22, 2010

We've received more reports of the Mac OS X 10.6.3 update causing problems with AFP file sharing, including AFP shares disappearing and Finder crashes. Dan Merino confirms the previous report:

With the 10.6.3 Update AFP crashes the Finder, which is unresponsive. I am in living hell with this latest update. My Mac Pro hasn't been stable since I applied the patch. I'm calling Apple to find out how to back out.

Robert Oschwald in Germany resets AFP on his Mac OS X Server to temporarily stop the problem:

Same issue here on a Snow Leopard Server. After updating to 10.6.3, AFP crashes every day. We must restart AFP Service to see shares again.

Richard Fleming also has to reset AFP on his Mac OS X Server:

You asked on your website if anyone had seen the shares disappearing issue. Well, I can confirm I've got the same thing. Since upgrading to 10.6.3 AFP breaks and shares vanish. The fix I've found is to use Server Manager (or whatever other method you like) and stop AFP and then start it again. This cures the problem for a day or so, until it happens again, then another stop/start and its working again. Sounds like the update has introduced some sort of resource leak into the AFP stack and I would hope Apple are treating this as a priority bug. Then again, maybe they're not. Meanwhile I'm stopping/starting AFP every day.

Ian Milnes sees the problem when trying to access a Mac running Mac OS X 10.4:

Me too -- an unresponsive Mac on 10.6.3 with AFP. Especially noticeable to my wife's iBook on Tiger [accessing 10.6.3], but I suspect also my Airport Extreme connected disk. But the Finder's fallen over -- it's difficult to tell what's done it.

Restarting my MacBook with my wife's iBook down also does the beachball of death on my MacBook. So I suspect possibly AFP shares on the drive connected to Airport Extreme are doing it. (Well for me anyway)

If you can think of a fix

Suggestion for AFP 10.6.3 bug: automate AFP stop/start on server

Monday, April 26, 2010

David Shauger responded to our report about stopping and restarting AFP service on Mac OS X Server as a way to get around AFP problems in Mac OS X 10.6.3 clients:

I haven't seen this issue yet, but I wonder about the AFP stopping and being fixed by restarting. When 10.5 Server came out they had a similar bug and I set up a shell script to run every five minutes that would disable and enable guest access via AFP. That kept the problem from happening. Perhaps that will help in this situation as well.


Tip: Fix for 10.6.3 AFP problems with Linux server

Thursday, April 22, 2010

Like other readers, Phil McLean was experiencing problems accessing an AFP server with Mac OS X 10.6.3. He made some changes to his Ubuntu server, and all is now well:

I have an Ubuntu file server serving volumes over AFP, have been using it over a year. In Snow Leopard, I am no longer able to access the files after a reboot (I'm not sure when it upgraded to 10.6.3). The volume appears in the Finder, but when I click on it and enter the credentials, it says, "You entered an invalid username or password." I tried repair permissions on the 10.6.3 root filesystem, then a reboot, but the problem persisted.

I re-applied the setup and configuration to my Ubuntu AFP server, and the shares are now accessible from 10.6.3 without changes, so I guess the config on the Ubuntu box got overwritten somewhere. The instructions I followed are from this blog.

If you've tried this


Reader says 10.6.3 update breaks printing | Top of Page |

Wednesday, April 7, 2010

Mike Sessums reports that updating to Mac OS X 10.6.3 causes the Mac to no longer see the printers:

I'm running into printing issues after the system updated to 10.6.3. My printers disappeared and I can't add them back. They are wireless printers.

If you've seen this problem

TIP: repair permissions for 10.6.3 printing and AFP problems

See article above.

Mac 10.6.3 update disables DeployStudio printing in AD, and a fix

Tuesday, April 20, 2010

Rhys Forrester reports that installing the Mac OS X update 10.6.3 disable printing on Macs deployed with the freeware DeployStudio:

We manage printers for Mac via an Active Directory and print through the ksmb client off of DeployStudio. We've just worked out that 10.6.3 overwrites the ksmb client with Apple's own ksmb client which doesn't work. Reinstalling the Deploy Studio copy fixes it straight away.

If you've seen this

Mac OS X 10.6.3 printer issue plagues reader

Tuesday, June 15, 2010

Federico Gianni agrees that the 10.6.3 update causes Macs to no longer see the printers:

It's a real and BIG issue. I can't believe that Apple programmers let this happen. I've lost all my network printers, and probably have to reinstall my Snow Leopard if 10.6.4 don't come soon.

As suggested, I tried repairing permissions via Disk Utility and this doesn't work for network printers. Thinking logically it shouldn't work, but I tried just in case.


Reader says 10.6.3 prevents Windows access to Mac printers

Tuesday, April 20, 2010

Dave Lapointe reports that the Mac OS X 10.6.3 update prevents Windows XP from printing to a shared printer connected to the Mac:

I've encountered a problem with shared printers since 10.6.3 update. Now when trying to print from Windows XP to a shared printer on the Mac I get an "Access Denied" error. The printer sharing is set to allow Everyone to print. I tried removing and re-adding the printer.

When I try to add the printer from XP it no longer shows up on the network. However, if I connect to the Mac through file sharing from XP and log on as an administrator then I can see the printer and add it. But I still can't print to it. The printer also no longer shows up when I attempt to add it from a remote Mac.

If you've seen this problem

Another reader says 10.6.3 prevents Windows access to Mac printers

Tuesday, May 25, 2010

Andrew Elmer sees the same problem as a previous report about the Mac OS X 10.6.3 update preventing Windows access to Mac-connected printers:

I too have this exact same problem however I'm accessing Snow Leopard from WIndows 7 Ultimate. Before upgrading to Snow Leopard the printing worked flawlessly. But ever since upgrading I cannot get the printer to work because windows 7 reports "windows cannot connect to the printer" and displays error 0x000003eb. Any help on this issue would be greatly appreciated.

TIP: HP driver may block Windows access to Mac 10.6.3 printers

Wednesday, May 26, 2010

Andrew Elmer updated his report from yesterday about Mac OS X 10.6.3 blocking access to printers from Windows 7 PCs. Today he sent us a fix:

I have had some success over the error. While I read somewhere that the error was associated with some HP drivers I didn't believe it was the driver because in the past I had used the exact same driver without any issues. But I finally decided to try and use another HP driver and indeed it did work. The printer I use is a HP Photosmart C4280 and the driver I tried to use countless times was HP Photosmart C4200 series. At the moment I can't recall the driver I use now but it works fine and the error no longer showed up the driver install correctly and now I can print from Windows 7 Ultimate to my shared Snow Leopard printer.

If you've seen this

TIP: Avoiding Finder hanging on SMB Linux -- keep .DS_Store writable

Monday, May 3, 2010

Erik Pearson has a workaround to problems of the Finder freezing when access SMB (Samba) directories on a Linux server. He is also running AFP on the same server, and provided information on how to run both netatalk and samba. His report:

Malcolm Heath mentioned a problem on your site that's similar to one I was having, where the Finder would hang when accessing subdirectories of a Samba share point. I discovered the source of my problem, in part through information on this post to an Apple support group.

I'm concurrently running netatalk and samba against the same directory tree, following guidelines prescribed here.

However, the veto files line for my share in /etc/samba/smb.conf includes the file .DS_Store. For Mac clients accessing the share using SMB instead of AFP, the .DS_Store file needs to be accessible and writable, otherwise the Finder will hang trying to create it. Hope this helps!

If you've tried this approach for this problem

Reader verifies .DS_Store writable tip for SMB Finder freezes

Tuesday, June 22, 2010

DNK confirmed a suggestion for Linux SMB servers to keep the Mac Finder from freezing when accessing it. The fix is to edit the /etc/samba/smb.conf file on the server to keep .DS_Store files writable by changing the veto files parameter:

This solved my issues with the browsing of sub directories. Before, I could connect to the share, and see only the top level. If I wanted to go deeper in the hierarchy, I had to relaunch the Finder. I removed my veto line that killed the .DS_Store, and all started working. This veto line was never an issue for me in older versions of OS X.

If you've tried this

TIP for Snow Leopard issues with SMB: keywords, WINS, & case sensitive Samba

Monday, May 3, 2010

David Lippa sent some solutions for fixing Mac OS X problems with SMB (Samba) file sharing, with Linux and Windows servers. He recommends a keyword, keeping a single WINS server in a subnet, and configure a Samba server for case sensitivity. Lippa's report:

I have some fixes to some of the Snow Leopard problems with Samba.

1) Use the "hide files" keyword instead of "veto files." The Man page says that they won't show up in Explorer (speed things up) but if you know what you're looking for (that's you, Finder!) you can access them.

2) WINS server issues. There can only be one WINS server *per subnet*......
Read entire story here

TIP: Remove space in directory name helps SMB issues

Monday, May 10, 2010

Alain Létourneau in Montreal reports that removing a space at the end of a shared directory cleared up SMB file sharing problems with Snow Leopard:

We are replacing old iMacs running OS/X 10.4 and when testing with the new iMacs running 10.6.x we had problems accessing files in some directories and not others (the files were on a Mac server running 10.4, shared via SMB), we finally figured out that the directories we were having problems with had a space for the last character in the name.

Everything worked fine when we removed the space character at the end of the directory name.

If you've tried this

Current news on the MacWindows home page


TIP: folder names with periods on server show up empty

Tuesday, May 25, 2010

Doug Yunker reports that Mac users that include periods at the end of file and folder names on a server can't access them:

I fixed a problem with Leopard and Snow Leopard not viewing folders on my Windows shares. Panther and Tiger worked fine. My Mac users were saving files and folders with spaces or periods at the end of their names. NTFS permissions couldn't apply, and the newer Macs could see the folder initially, but when they try to open them, they would be empty or disappear. I had to rename them with the Panther computer, and then everything worked fine.

If you've seen this behavior

TIP: Empty SMB folders may be DFS servers

Monday, July 12, 2010

Ryan Palamara responded to TIP: folder names with periods on server show up empty, with a reminder about accessing servers using Microsoft Distributed File System (DFS) systems:

One thing to make note of is that OS X will not work with DFS setup on a Windows server. If you have a mac and browse to a DFS share, you will see the folders, but they will all be empty. You will have to find the true UNC path of the share and browse to it that way.

We would add that there are some third-party solutions that give Macs access to DFS, including Thursby Software's ADmitMac and Group Logic's ExtremeZ-IP.


Snow Leopard "139" SMB tip works for slow login prompt

Tuesday, June 29, 2010

Brett Bergerman used the smb://share:139 workaround, previously reported to get around SMB file sharing problems in Snow Leopard. However, he used it for a different SMB problem:

I was getting a different symptom in that my Mac, when connecting to my PC share, would take about 15-20 seconds to display the login prompt for the PC's credentials. The connection would then work fine. However, now that I have specified the TCP port in the Connect to Server URL (:139), I no longer have to wait for the prompt. Thank you very much for the tip - this fixes a very frustrating issue for me.

If you've seen this slow login prompt issue and have tried this workaround

Does server:139 SMB logon clear old credentials?

Wednesday, June 4, 2010

Charles Powell has a thought as to why using server:139 to log on to a SAMBA share works for some people:

This worked for me as well with OS X 6.4. I could connect as other users but not as myself. I guess changing the port designation cleared the prior credentials.

What do you think?

Using smb:\\share:139 to fix slow SMB with big files

Monday, March 21, 2011

Two readers commented on the tip to speed Mac OS X's SMB browsing by connecting manually by typing smb:\\share:139 in the Finder's Go menu>Connect to Server. Marnina Norys tried some of our other tips, unsuccessfully, then found that simply typing smb:\\share also worked for big files:

I recently updated my Mac to Snow Leopard and was horrified by the lags I suddenly faced when I tried to access large files on my external Western Digital network drive. After attempting to apply a few of the fixes such as the nsmb.conf tip, fiddling with ACK settings and turning on Internet sharing I was getting sort of frustrated. Eventually I tried to connect to Server using smb:\\share:139, and voila. Although files in large folders take a while to load, once they are up I can browse quickly and easily. Before it would have taken about a half an hour to get to the bottom of my iTunes folder with the bloody spinning wheel coming on every few seconds.

After I noticed that this fix seemed to work I saw that shares on the Network drive are getting mounted as AFP, which might be what is causing the delay. I dropped the 139 from the server address and found that browsing shares without it was just was fast. It was specifying smb that was important for me. If I go into the drive through the alias on my desktop, however the shares mount as AFP and it's laggy as ever.

Darbo Scalante was successful with smb:\\share:139:

Just want to say I tried and it really works, thanks.

Reader says tips don't fix slow Mac SMB file sharing

Wednesday, April 20, 2011

Alexander Henket tried out four of our popular tips for speeding up SMB file sharing in Snow Leopard. Although many readers have reported success with some of these, Henket found none of them worked:

I've tried setting the FQDN, the port 139, the delayed_ack, the notify_off with reboots in between. The net result is unchanged in that making initial contact to any SMB share takes 22.5 seconds. After making initial contact browsing and copying works just fine, but if I happen to close the last Finder window on that share, it takes yet again 22.5 seconds to connect. Mac OS X 10.6.7 connect to a Windows Server 2010.

If any of these work (or don't work for you)


TIP: fix for Finder not deleting files on SMB Linux share

Thursday, September 2, 2010

Alexis Rosen forwarded a fix for problems with Snow Leopard clients not being able to delete files on Linux SMB shares. There were also issues copying files. The fix is to edit the /etc/samba/smb.conf file on the Linux server. Editing this file can fix other issues as well. This time, the trick is to remove the "netbios name = XXXXX" line. Rosen's report:

I am running a stock Ubuntu Lucid, fully updated, with the standard Ubuntu packaged samba (v3.4.7). I spent several hours trying to get it working properly with OS X 10.6.4 last weekend. This is a new installation, so I have no track record of previous success or failure with this combination of software.

The problem I was seeing was that the Finder could not delete files within folders of the share, failing with the message "The operation can't be completed because you don't have permission to access some of the items." Also, copying files into folders would work, but the Finder would leave them with a file type of "brkn", making them greyed-out and somewhat inaccessible, and again would report the permissions error. As hinted by some of your earlier mail on the subject, this seems to have something to do with either file icons (left incorrect by the Finder, because of the "brkn" file type) or perhaps extended attributes, which would look quite odd when examined from the shell (for example, two identical extended attributes on the same file, sometimes). However, changes such as turning off icon preview or prohibiting use of streams (in /etc/nsmb.conf) on the Mac client side were ineffective. Also numerous changes on the samba server side (such as "unix extensions = no") didn't help at all.

After a great deal of useless work, the fix turned out to be ridiculously simple and frustrating. It was to remove the "netbios name = XXXXX" line in the [global] section of /etc/samba/smb.conf. (Other Linuxes will have that file in /etc or elsewhere -- consult the man pages.) Unwilling at first to believe that the fix was so simple -- and so bizarre, given what that setting does -- I tested this a few times, changing only that option and restarting smbd. Setting it was 100 percent effective at causing the problem, and unsetting it 100 percent effective at fixing it.

If you've tried the approach


Question on network trash folder on Linux server

Thursday, September 2, 2010

Alexis Rosen has a problem with a Linux server and a network trash folder with Mac clients:

If anyone knows how to enable a functioning trashcan on a network share (either AFP or SMB) I'd love to know about it. I see that my share has a "Network Trash Folder" and that netatalk knows to hide that from me, but I still can't hold files in the trash - the Finder destroys them immediately upon throwing them out (after warning it's going to do so). There was some comment on the netatalk mailing list *years* ago that this was "known broken" and that Apple was working on it. I didn't even try to see if samba could use one. (Apparently samba has a VFS module that will put all removed files into a trashcan, but that doesn't help me with netatalk, and I'd like something more Mac-like if I can manage it.)

If you know the answer

Netatalk's network Trash folder a relic from the past

Tuesday, September 7, 2010

Bryan Schappel has an answer to last week's reader question about the inability of Mac OS X to use a Network Trash folder created by a Linux server:

The folder that netatalk creates is for Mac OS 9 clients. The ability to use the network trash folder was removed from OS X. Back in the days of 10.1 I went around and around with Apple on the demise of the network trash folder. Apple said they removed the functionality because other operating systems on the market had no such functionality. Since OS X can connect to file servers over various protocols (SMB, WebDAV, etc.) having AFP provide a network trash folder would be inconsistent. I tried to argue that removing a feature that Mac users loved since the invention of AFP was more inconsistent, but I was not successful. Managing the network trash folder is actually the responsibility of the client and not the server. The AFP client in OS X does not support this feature anymore.


Snow Leopard files disappear when copied to SMB share

Tuesday, September 7, 2010

Stephen Farr reports problems with browsing SMB file sharing in Snow Leopard, as many readers have, but also finds that some files copied to the share disappear:

I have the same problem as James Spencer reported last year. All my home-based business is on an SMB share and I do all my work on Macs. I am dead int he water because Snow Leopard Finder no longer shows on my Macs any SMB folder to which I have written from another Macs. Also, when you save a file to an SMB volume from some apps, such as TextEdit, it is invisible to Finder. You can see it in the Save File dialog from the App that created it, but not in the Finder. Snow Leopard is a disaster. To be able to work again, I need to revert all my Macs back to Leopard - not a happy undertaking!

If you've seen this problem

Specifying new network location can help wireless SMB filesharing

Monday, September 20, 2010

Peter Duniho found that one of our older tips on our Leopard page fixed his problem with SMB file sharing on a wireless network. Basically, he created a new "location" in System Preferences>Networking and specified Workgroup as the workgroup name:

Once again, your web site has saved the day.

Today's problem was the sudden failure of my Mac to be able to see any of my Windows LAN. I've made a few changes since the last time I accessed the LAN via my Mac, but none seemed likely to have caused a problem. Downloaded security updates, installed Parallels 5, maybe some other stuff. All I knew was that I kept getting errors from the Connect UI in Finder.

After browsing a number of SMB-related messages on your site, I came across this one.

I've never had problems moving from one site to another before, but it did happen that I'd been using my laptop at someone else's house once a week or so, and so there was the possibility that the "Automatic" location logic in OS X was getting confused.

Sure enough, creating an explicit location and setting it up for my LAN (including the default "WORKGROUP" workgroup name), now all of the sudden I can connect to my Windows file shares again.

Of course, I cannot say with 100 percent certainty that that's the change that fixed things. But I didn't change anything other than that between reproducing the problem and seeing it go away, so it seems _really_ likely to me.

Snow Leopard problem connecting to Win SMB after wake from sleep

Friday, October 22, 2010

If Michele Lundquist's MacBook is connected to a Windows 7 SMB share before going to sleep, it can no longer access the share after waking. Only restarting the SMB service on the Windows PC fixes it:

I came across your site when I was unable to connect to shared folders on my Windows 7 computer from my MacBook. Before updating to Snow Leopard, I could connect without a problem. My problem started after I copied my iTunes library from my Windows computer to my Mac over WiFi. Then, while the Mac was still connected to my Windows computer via SMB, I closed the lid and put it to sleep. After that, I could not use Connect to Server to get to my Windows computer. The Windows computer didn't show up as shared in Finder, either. I could use Remote Desktop Connection to connect. The error said it was unable to connect, not that it could not find it. This reminded me of an error I occasionally see when connecting a (Windows) client to a default share on a Windows 2003 server. I never see this error when connecting to shares I have manually set up. Here's the error:

1219 Several connections to a server or a shared resource by the same user, using more than one user name are not allowed. Remove all previous connections to the server or shared resource and try again.

So I checked sessions and open files in Computer Management. No connections are listed. So, I restarted the Server service. It supports file, print, and name pipe sharing. I was immediately able to connect to the Windows share (default) again. It seems that the connection was still open, but in an unusable state.

If you've seen this problem

Fix Confirmed: Restarting SMB Sharing Service on Windows 7 fixes post-sleep connection issue

Monday, November 15, 2010

Jason Morley-Nikfar confirmed a fix for a problem where a Mac can no longer access an SMB share after waking from sleep:

I just wanted to confirm that the fix in the post titled, "Snow Leopard problem connecting to Win SMB after wake from sleep" from Friday 10/22 did fix the same problem for me. I was also having difficulty connecting to a windows share after waking from sleep. The Mac went to sleep while copying a file to a Windows 7 share. After waking, it could no longer connect to the server by IP or hostname. I restarted the file sharing service (known as just the "server" service on Windows 7) and this immediately fixed the issue. Please relay my thanks to Michele Lundquis for this tip!

If you've tried this fix

TIP: Fix for Mac access to Win Server 2008 R2

Monday, November 29, 2010

Daniel posted a fix in our File Sharing discussion forum for a problem where Macs could no longer connect to Windows Server after updating it to 2008 R2. The fix involves changing a setting on the server to allow cryptography algorithms compatible with Windows NT 4.0. Read how in the forum -- if this works for you, please post a reply.

TIP: Eliminate "dot underscore" with named streams on SMB NAS and servers

Monday, November 29, 2010

Daniel Öhman in Sweden sent us an Apple article called "Mac OS X v10.5, v10.6: About named streams on SMB-mounted NAS, Mac OS X, and Windows servers." The article describes how turning off named streams in Terminal can prevent errors in SMB access for network attached storage and file servers. In fact, this an explanation for a tip that we've previously reported for the -36 error message. Öhman and the article also say that this fixes another issue:

I found a very nice way to avoid AppleDouble (._) "dot underscore" files on SMB shares. It requires minimum Mac OS X v10.5 with manual enabling. Mac OS X v10.6 seems to handle Alternate Data Streams / Named Streams automatically. See this Apple article.

If you've tried this

TIP: suggestion for Snow Leopard/ Win Server unmodifiable folders: files that become read-only

Friday, December 10, 2010

Graham Patterson sent us a simple suggestion for Snow Leopard problems of not being able to make changes to SMB shares on Windows servers:

It is often possible to sort out the permissions on new folders created on Windows shares by 10.6 Macs by doing a Get Info (Command I) on the offending item. That seems to re-sync the permissions from Finder's perspective.

It is not a universal fix, but it does help with some otherwise inaccessible folders/files on Active Directory systems. A lot depends on the Windows permission settings, and whether the Mac is joined to AD.

If you've tried this

This approach was suggested once before on this page, for a similar problem with Office files and Adobe files. However, the Mac OS X 10.6.3 was supposed to have fixed it, according to Apple.

It's back: CS4 files copied to Win Server become read-only, and workarounds

Monday, December 20, 2010

Thomas Zwack reports that on new Macs, Adobe Creative Suite 4 files that are saved from within the application to a server become read-only to other users. This is the same problem that Office and Adobe users once had with Snow Leopard, but which was reported to have been fixed with the 10.6.3 update. One reader last week suggested doing a Get Info on the mounted share on the Mac, which he said seemed to refresh permissions, but this didn't work for Zwack. He did have some workarounds that:

We recently purchased and installed 8 new Mac's. Our users are able to connect to our Microsoft file server and create a file and work on it. When they go back to the file or someone else tries to open it, everyone now gets Read Only permissions. When we check the file permissions on the server, the users are set to have read write access. We can force the Microsoft file share to basically, republish the file permissions down and it fixes it until the next user creates a new file again.

Another workaround is for the user to save the changes to a new file on their desktop and then copy it back out to the network drive and replace the existing file. Which is extremely odd since that's what they were trying to do from with the application basically.

The updates and suggested fixes, unfortunately, do not help. It does appear to be an issue with only the CS4 files. Creative Suite and InDesign. The users create the file on the network, save it, close etc. When the same user comes back to the same file later and makes a change, they get read only when they try and save. They save to the desktop, then copy it back out and replace the file on the network with no additional error? This suggests to me that the network permissions are not causing the issue because it allows them to replace the file. There is a lock or something being retained on the file that has to do with CS4 is my thought.

If you're experiencing this problem

Save As may get around read-only CS4 file server problem; also seen on NAS

Wednesday, March 9, 2011

Two more readers responded to the Snow Leopard report "CS4 files copied to Win Server become read-only, and workarounds." Gary Whitehead recommends using Save As:

We have the same problem. All files saved from CS4 seem to be read-only when opened by other users. I have found that using Save As works better than just using Save.

Adam Gibson in Australia sees it on a network attached storage (NAS) device:

I am experiencing this exact issue in Snow Leopard also.

  • Seagate NAS Blackarmor
  • Ethernet network of 5 iMacs
  • When working off the NAS directly on an Adobe file, saving every now and then says "Cannot save this file due to access privileges error code -5000." It only happens on some files.

If you know of a workaround, or have tried using Save As

More on ACL permissions changing with 10.6 client and Win Server

Wednesday, June 1, 2011

Jim responded to the post called "Suggestion for Snow Leopard/ Win Server unmodifiable folders: files that become read-only," which did not help him with a similar problem:

We are running an XServe where we host our store/file shares. We use posix and ACL lists. The ACL list is set across the board as

User Admin : Read Write
Group Admin : Read
Others : No Access

We run a mixed environment. XP Clients and Snow Leopard Macs. We noticed that some times the ACL would change from user_admin to user_name when a file was saved. This prevents a read/write copy being opened by anyone else.

Lately it has started doing it with MAc users too. Mostly in our Design Department.

We can theorize that there's some kind of ACL inheritance setting here that is messing things up. If you have an idea


Reader says deleting folders on SMB server randomly freezes

Monday, February 21, 2011

From our forums, Stuarta writes:

Have a Mac on 10.6.6 which is connected to a share on a Windows Server 2003. Majority of the time the file access is fine, but every now and then when deleting files, the progress bar will freeze, not do anything and lock the folder. The only way out of it is to reboot the Mac.

If you've seen this, post a note here.

Reader's Finder color labels not displaying on some Windows shares

Monday, March 21, 2011

Sonja Kirsch in Bavaria reports that for file and folder color labels (assigned in the Finder's file menu) don't appear on some Macs when the files reside on Windows workstations:

We have a problem with Mac 10.5.8 and 10.6.6 with files stored two PC workstations (Windows 7 64-bit and Win XP SP3). The two Mac users don't see each other's color labels: That is, Mac 10.5 users see color labels of themselves but not the labels of Mac 10.6 users (and the other way around).

On our third server, Windows 2008 server R2, color labels work fine and we can all see our each other's labels.

I'm referring to the labels that Mac users can use for files and folders. It's very convenient for organization (for example: red = to do, green = finished). So all Mac users that are on the server are informed about the status of the file.

If you've seen this problem

Another case of Macs not seeing Finder color labels on Windows shares

Tuesday, June 28, 2011

Steve Perry confirmed a previously reported problem regarding Macs that can't see file and folder color labels on files on Windows network shares:

I just installed 10.6.7 on my Mac and am having exactly the same issue as below. I can't see other Mac users labels and they can't see mine on the server. We use a similar system where the Finder Colour Labels are essential for letting us know what stage the job is at. Causing me some major problems. Anyone any got ideas? We're using a Windows Server 2008.

If you've seen this problem

TIP: Suggestions for Finder Colour Labels not displaying on Windows share

Friday, July 1, 2011

Steve Perry followed up his previous report "Another case of Macs not seeing Finder color labels on Windows shares" with some suggestions and wo Apple articles. One is called "Mac OS X v10.5, 10.6: Finder label changes to files/folders mounted via SMB may not appear to other clients." The other article is about named streams on SMB servers and the -36 error, something we reported on before. Perry wrote:

I've been sent these "fixes" (here and here) by our Microsoft technician. They're not very practical, though, as we would have to make sure all Macs using this network would have to update to OS 10.5 at least and we're just not in a position to do that at the moment. Also you need a pretty advanced knowledge of Terminal and networking systems should you need to undo what you've done. I'm not brave enough although they may be useful for someone else!

If either of these Apple procedures fix this problem for you .

Since 10.6.7, reader's Mac can't open NAS, Win can't access Mac

Monday, May 2, 2011

Since upgrading Mac OS X to 10.6.7, Ted Leeuwesteijn cannot open shares on a network attached storage (NAS) device. Additionally, his Windows PCs can no longer access Mac shares:

Since the 10.6.7 update I still can see and connect to my SMB NAS on the network, even see the shares -- but I cannot open them. I tried the older known tricks, Win XP machines, HTTP, FTP access al works well accessing the NAS. Tried to reconnect as anonymous, and as user. But there is no access to the shared folders from the Finder whatsoever. They are visible, just nothing to read. And when I try to open them it nags me about the right IP address or name. Well I can ensure that it is the right address even when I type it manually.

Also, other Windows machines cannot access my shared files anymore since that same update, which was never a problem in 10.6.6. I checked the shared and network settings but can't find anything out of the ordinary.

If you've seen this problem

Another reader says 10.6.7 broke Mac access to NAS

Monday, May 23, 2011

Simon Block said updating to Mac OS X 10.6.7 broke file sharing in two directions:

Saw the post "Since 10.6.7, reader's Mac can't open NAS, Win can't access Mac." I'm in the same boat since going OS X 10.6.7. I can see shared folder on NTFS disk on my Windows Vista machine, but can't access the folders on my FAT32 NAS.


Does DFS slow Snow Leopard SMB file server access?

Monday, June 6, 2011

Hollai Gábor believes that Snow Leopard's access to SMB file servers slows down when DFS is used on the network:

We have removed the DFS feature from one server and the SMB is better now. Both DFS caused the issue, Standalone and the domain DFS too. Unfortunately, we must use DFS on the second server, so the issue is still exist when we use that one.

If you've seen this issue

Problem with multiple large SMB file copies, but folder copy is OK

Monday, June 20, 2011

Daniel Kimbro that when copying multiple (large) files to a Windows PC, some simply don't copy. His workaround is to put them in a folder and copy whole folder:

I came across your site while looking for a solution to this problem. I have a Windows 7 machine with a 1.5 Tb drive that I use for a video file server. Occasionally I copy files from my Mac laptop across the network via SMB to the drive. If I tried to copy more than 2 or 3 files, some of the files don't appear on the other side. This has been going on since my move to 10.6. For instance, earlier I tried to copy a bunch of episodes of a show to the drive from my laptop. There were about 20 episodes and it came out to around 4 or 5 gigs. It took a while but then completed. When I looked on the other hand several of the files hadn't transferred. The odd thing is that it wasn't linear. The episodes were in order from 601 to 619, and the ones that didn't stay copied were 604, 605, 610, and 615. Then a few minutes ago I tried copying a few episodes of another show. It was like 1.26 gigs this time, but instead of copying them as a set of files I just copied the containing folder over and it worked just fine. Right after that I copied a high def movie to it over 6 gigs and it copied just fine. It seems to have trouble copying multiple files. If you copy a single file or folder it has no trouble with it.

If you've heard of this issue

TIP: More workarounds for big file copies to Windows PC

Tuesday, June 28, 2011

Leslie Alexander responded to last week's report about a trick of copying large files in a folder from a Mac to Windows workstation to get around a problem where the files just don't copy. Alexander offers another two workarounds, including using a Mac-formatted drive in Windows with Mediafour's MacDrive 8, which enables Windows to read and write to Mac-formatted (HFS+) drives:

I had the same problem that is being described by Daniel Kimbro, as far as I know there are two solutions:

  1. Copy only 1 or 2 files at a time, wait for the first 2 to complete then transfer your next two; or
  2. Get MacDrive for Windows, assuming the Windows hard drive you're copying to is a secondary or external drive -- format it to HFS+ and you can transfer any files you want and as many as you want worry free.

If you seen this issue

Suggestion for big file copies to Windows problem

Friday, July 1, 2011

A reader suggested using Thursby Software's DAVE SMB file sharing software to avoid the problem of multiple large files not getting copied to Windows SMB shares from a Mac:

They should also be able to resolve this using DAVE. [Thursby] still has free evaluations available so that they can confirm this as a solution.

If you've tried DAVE for this problem .

Snow Leopard SMB share reverts to root level randomly

Friday, August 5, 2011

Simon Deroles is seeing a problem with SMB file sharing where Finder window reverting to root level when displaying Windows folder directory. Other readers have reported a similar problems with Lion, but Deroles is running Snow Leopard:

I have an iMac running 10.6.8 connected to an active domain on a Windows 2008 server. I can login and open my Home$ folder just fine and drill down thru the directory. However the Finder window will always randomly revert to the root level of the folder. Sometimes this occurs after several minutes and sometimes in seconds. When saving a file to my Home$ folder this reversion to the root level can occur in the middle of a save as well - the directory in the save window disappears and is replaced by the root directory. I then have to drill back down to the desired folder level. I have access to another folder shared by all users and this is stable and does not revert to the root level. We have several other Macs on the network as well - all configured the same (apparently) and no one else has this problem.

If you 've seen this issue .


Localized-language characters revert SMB shares to root level

Monday, November 28, 2011

Melker Humala reports that removing non-English characters from an SMB share path fixes a problem with Mac OS X 10.6 clients:

Snow Leopard SMB share reverts to root level randomly when localized characters (such as Swedish) are used in the path. I came across this as I found a thread discussing this the problem was on a French magazine/paper and they used some non-standard characters as well.

If you've seen this issue

Current news on the MacWindows home page

Mac OS X Lion Server For Dummies
By John Rizzo

Learn how to install, setup, and manage Apple's Mac OS X 10.7 Server software. Support Mac and Windows clients for file sharing, email, and directory services; Integrate with Active Directory; Set up Profile Manager, configure security options, and more. Click here for more


Other MacWindows Departments

| Product Solutions | Reports and Tips | News Archives | Site Map |
|
MacWindows Home |

| Top of Page |

This site created and maintained by
Copyright 2009-2012 John Rizzo. All rights reserved.