Link to home
Start Free TrialLog in
Avatar of orbitsystech

asked on

OSX: Network drive browsing slow for network accounts

Background: I work in a mixed environment of Windows and Mac clients, both access network drives using the SMB protocol. All of the SMB shares are hosted on Server 2003, Server 2008, or Server 2008r2 servers. Windows machines can browse the network drives without slowdown (assume network drives are on site), however, all of the computers running the Mac OS have slow browsing problems (mostly OSX 10.6, but 10.5 and 10.4 have the same problem). All Macs are bound to the same Active Directory Forest/Domain and so users log in with Domain credentials.

Example: On a Mac running 10.6.6 I have a network drive mapped on my desktop, say to smb://server/serverCommon$. When I initially connect the drive it takes about 5 seconds to mount the drive (not a big deal), however, when I access a folder within the mounted drive, it can take a significant amount of time to open that folder, up to 30 seconds. There DOES seem to be a correlation between the number of items in a folder and the time it takes to display said items (e.g. a folder containing a few documents takes a few seconds, but a folder containing many documents/folders takes much longer). This problem is consistent for all of our Mac clients regardless of which Windows Server version they are running. On the same test Mac I have Parallels installed and the Windows install IS able to browse at a very quick speed.

The following configurations have made NO difference:
- Wired connection vs. Wireless
- Anti-virus vs. No-antivirus
- OSX 10.6, 10.5, 10.4
- Mapping drives by IP address as opposed to server Name

The following workaround DID make a difference (but is not a viable option):
- Using an unmanaged Mac and connecting to the network drive, I'm able to browse the network drive just as fast as Windows
- Using a managed Mac (bound to Active Directory), but logging into the computer under a LOCAL account (doesn't authenticate with Active Directory) and then using Domain credentials to connect to the network drives. Doing this allowed me to connect and browse network drives as quickly as a windows PC.

Testing Conclusion: based on the findings above there seems to be a very strong correlation between being logged into the Mac with a Domain account and browsing drives slowly.

My Thoughts: When opening a network drive on a Mac, the computer has to query the server as to what files/folders can be displayed using the credentials supplied by the user. For some reason, this process takes MUCH longer when the user is logged into the Mac using a Domain account than it does when using a local account. This may be due to a difference in how a Domain account authenticates with the SMB server vs. how a local account authenticates, even though it maps network drives using the same Domain credentials.

Question: Is there anything that can be done to speed up network drive access for users logged into a Mac bound to Active Directory with a Domain account? I've tried everything I can think of and simply logging into the Mac with a local account and mapping the drives with domain credentials is NOT an option. Thoughts?
Avatar of Owen Rubin
Owen Rubin
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of orbitsystech


Looks promising, we used to use ADmitMac before we just started manually adding Macs to the domain so I'm familiar with the company, just never heard of this program before. I'll give it a shot and post back, thanks!
I've looked at smb on 10.6 recently. Im sure its an alpha release of smb - very poor implementation too!

smbclient -V
smbd -V

Its actually worse than 10.5
and dont get me started on afp problems!

You could try looking into disabling indexing on the mac clients, and also stopping them from creating DS_Store files. Let me know if you need the commands for either of these.
orrubin - DAVE works fantastic, takes care of the problem. Only issue is that at $160 a license not all of our clients will go for it but I know a few won't hesitate, great suggestion!

gmbaxter - I'm pretty comfortable using Terminal so if you could post the commands to disable indexing and stopping the creation of DS_Store files I'll give it a try and let you know how it goes.

Thanks to both for the responses, feels nice to finally make some headway on this issue!
This turns indexing off - needs to be run on the clients

sudo mdutil -a -i off

This turns user DS_Store files off

defaults write DSDontWriteNetworkStores true

It needs to be run per user - or ideally, change one pref file and file blast it into all users areas.
Yea, the $160 is steep. You might contact them and see if they will grant some kind of site license, or group discount.  Never know.

Great idea to turn off indexing.

One other thought occurred to me as well from gmbaxter's message. I noted that when I have my virus program running on the Mac, every time I mount a server, it starts scanning it, as it does all new drives that get attached. And that REALLY slows things down greatly in seeing the drive. Check to see if you are running a virus program and if it defaults to scanning new drives (ClamXav does!) and disable that as well.


 - DAVE still works, though still looking for an alternative due to the cost.

 - Turning off Indexing unfortunately didn't fix the issue.

 - Turning off the DS_Store files didn't fix the issue.

Found a potential work around, however:
Quite by accident we noticed that when the Macs are using ONLY wireless, there is no slowdown so we figured it had to be something with the Ethernet so we tried the following:

In System Preferences, go to the Network preferences
-> Select the Ethernet connection and the click "Advanced".
-> In the Advanced Window, Select the Ethernet tab on the far right.
-> Set "Configure" to Manual, "Speed" to 10baseT/UTP, "Duplex" to half-duplex, and leave MTU at Standard (1500).

Tried this on all three of the managed Macs at our office and it works. I brought it up to one of our network engineers and he's guessing that when the Mac is set to automatically configure the Ethernet Protocol, it isn't negotiating properly with the switch (or at least that's how I'm translating what he told me).

I'm going to do some additional testing and see if any other variation other than 10baseT, Half-duplex will work...
How odd, so you turn DOWN the speed of the Ethernet, and then you cut its speed by one order of magnitude (100 default automatic or faster if available to 10) and then in s much as half by setting half-duplex so only one direction talks at a time, and you got faster response. OK, I am baffled.

Hard to believe that your office is not using AT LEAST 100 Base T switches or faster, nor do I believe that they cannot speak full duplex, so I question this logic. Can you try setting them back one at a time and see what happens? I would start with 10baseT/UTP back to 100 Base TX and see what happens? I am wondering if the Mac only speaks UTP over 10 Base T properly, and this corrects the issue.

So, first 100 BT, then try only Full Duplex, and see which causes the problem to go away.

Personally, I am baffled that your solution makes the network work faster.
Found a full-duplex solution:

I tried every combination of 10/100baseT and half/full-duplex and the best combination I could get was 10baseT, Full-Duplex W/Flow-Control. Not exactly sure what Flow-Control does but it seems to allow me to use Full-Duplex which is a big step up. Going to test with customers and see how it works for them, my concern is that this will be environment-specific but I'm crossing my fingers that it's not.
Damn network error erased my response. Let me try again before the network fails again.....

FLow control is like they used to have on old serial lines, where you can start and stop the data from flowing when one end get near to "overflow" of too much info. Not sure why one end is having problems with too much info however, but it explains why the faster speed fails. Half duplex probably hid this problem since only one side could talk at a time, giving the network time to catch up. Odd.

I am wondering if you can try one more experiment? Is it possible that Active Directory is causing the problem? (Since you said Dave solves the problem.) I am wondering if you could create a no credentials share on the network drive, and then try connecting from the Mac to that share with the original all automatic settings on the Mac.  I am not sure where in your topology your active directory sits, but I wonder if the connection to and from that service is slowing down the Macs for some reason?
another thing to try is put macports on a client mac and update the smb client.

install and then open terminal:

sudo port install smb

Its like a package manager for os x, similar to linux's apt get or yum
I tried changing the Network preferences on a client Mac at their office and unfortunately it didn't make a difference on their network, even when switching to half-duplex.

I did have him try DAVE and it worked perfect for him right from the start so at least that fixes it consistently!

As I alluded initially, there are multiple customer sites that experience this problem so I'm going to try your the Network preferences fix that works in our office. Will post what I find out.
I've implemented the duplex/10baseT fix I listed above on another client's computer. Unfortunately they are horrible at getting back to me so I'm not sure if it worked or not.

Skshoup - I didn't see this before and is a good find! We have a test server to try it out on but unfortunately it's server 2008 R2. Do you know off hand if the fix is supposed to work for later versions? I don't see any of the registry values listed.
Wasn't able to find the registry keys  mentioned in the solution by skchoup in Server 2008 R2.

I did come across some other fixes that may be helpful to others who have similar issue (unfortunately they did not fix my problem):

1: go into preferences and go to: Network -> Advanced -> Ethernet. In here change the MTU setting to "Custom" and try making it smaller. From what I've been able to find out, changing this setting changes the packet sizes, making them smaller means packets finish transferring more quickly, though obviously that means more packets will be sent.

2: edit the smb.conf file by adding "large readwrite = no" (without quotes) to the Global section.
     - open Terminal and enter: sudo nano /etc/smb.conf
     - enter password when prompted
     - use keys to scroll down to the bottom of the [global] section and enter: large readwrite = no
     - hit Control-O for the WriteOut function and hit enter (saves the file).
     - Control-X to exit, then reboot
OSX 10.6.7 was released a couple weeks back and it specifically addressed issued with the SMB protocol. Unfortunately the update did nothing to fix the problem we've been experiencing.
I will try some other things, but I just believe this is a bad protocol on Mac's part, which is why Dave fixes it.  If I come up with more ideas, I will post.
Still an issue and we havent been able to find a solution, any other suggestions?
I am stumped. Curious, if you reboot the Mac, is the first access any faster than later access? I am wondering if this is caused by bad caching?
orrubin: Sorry I let this go so long, company got bought out, lots of changes happened and things ended up getting put aside. To answer your most recent question the problem happens right away but I wouldn't rule out a Caching issue. Once I load a folder and it Caches then navigating the network drive is more responsive. If we were talking a network folder with a couple other files/folders in it then it wouldn't be a problem, but for most of our customers the issue is really apparent when connecting to a common drive with 50+ directories and hundreds or thousands of files.

When I first came across this problem a couple years ago I thought it might be an issue with Caching (and it might actually be), but most of of our customers have their Domain Controller on site and so they are accessing the files on a local network with at least a 100baseT. This being the case, I would think Caching should be pretty instantaneous.
Sorry, been away, so have not been able to respond lately. I am still baffled by the network speed issue with wired. Sounds almost like there is an old 10Base-T hub or switch between the computer and the destination which is slowing things down. Especially since the Wifi works well.  Maybe they can connect their Mac by wire temporarily closer to the server and see if anything changes? That would at least eliminate most of the physical network from the problem.

With the other suggestions here, not sure what else to suggest?

I did find this possible alternative to AdmitMac but not sure it will work for you. You can try it:

MSAD Login is an active directory plugin for OS-X:
Thanks for the suggesting orrubin, I haven't seen the MSAD Login option before so I'll give it a go!

As far as any hub issues, we moved into a newly refurbished building a couple years ago (when I first started troubleshooting this issue) and the building was completely gutted as part of the remodel. All our network equipment is at least 10/100, most 10/100/1000.

One of the Sys Admins informed me he was considering changing the smb protocol on the server. Not super familiar with it but he informed me it was running SMB2 and he was going to try setting it back to the previous version to troubleshoot a different browsing issue a customer of ours was having.

I'll update with what I'm able to find out with both the above solutions. Thanks again!
Cool. Let me know. Thanks.
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Guess there was some problem in the previous version of OS-X. Good to know that Lion fixed the problem. Thanks for letting us know.
There appear to be no actual fixes to this problems, just work-arounds that do the job via programs that take over the job (such as DAVE, by Thursby) or upgrading to OSX 10.7.