Solved

OSX: Network drive browsing slow for network accounts

Posted on 2011-02-15
26
8,438 Views
Last Modified: 2012-06-27
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.

Testing:
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?
0
Comment
Question by:orbitsystech
  • 13
  • 9
  • 3
  • +1
26 Comments
 
LVL 10

Accepted Solution

by:
Owen Rubin earned 500 total points
ID: 34929072
I have seen this problem before, and chalk it up to a poorly implemented SMB protocol on the Mac. When folders get large on the Windows side, it seems as if it builds a directory every time it accesses the folder or drive.

I tend to use the software Dave by Thursby, which implements its own file handling (Full support for Microsoft Distributed File Systems (DFS) and SMB/CIFS network volumes) and works MUCH better than the Mac handling of the drives. You can download a trial (I am not associated with the product in any way, just like it) and see if it solves the issue.

Find it here: http://www.thursby.com/products/dave.html

There is a free eval link in that page.
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 34929538
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!
0
 
LVL 11

Expert Comment

by:gmbaxter
ID: 34939405
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.
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 34947692
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!
0
 
LVL 11

Expert Comment

by:gmbaxter
ID: 34956210
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 com.apple.desktopservices DSDontWriteNetworkStores true

It needs to be run per user - or ideally, change one pref file and file blast it into all users areas.
0
 
LVL 10

Expert Comment

by:Owen Rubin
ID: 34957871
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.

Cheers
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 34965703
Updates:

 - 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...
0
 
LVL 10

Expert Comment

by:Owen Rubin
ID: 34965834
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.
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 34975075
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.
0
 
LVL 10

Expert Comment

by:Owen Rubin
ID: 34982499
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?
0
 
LVL 11

Expert Comment

by:gmbaxter
ID: 34983014
another thing to try is put macports on a client mac and update the smb client.

http://www.macports.org/

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
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 35021875
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.
0
 
LVL 2

Expert Comment

by:skshoup
ID: 35073581
0
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 
LVL 1

Author Comment

by:orbitsystech
ID: 35159704
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.
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 35210887
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
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 35387295
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.
0
 
LVL 10

Expert Comment

by:Owen Rubin
ID: 35387411
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.
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 35827443
Still an issue and we havent been able to find a solution, any other suggestions?
0
 
LVL 10

Expert Comment

by:Owen Rubin
ID: 35827697
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?
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 37519723
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.
0
 
LVL 10

Expert Comment

by:Owen Rubin
ID: 37562207
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:
http://www.pa-software.com/products/overview.php?prod=4719B749
0
 
LVL 1

Author Comment

by:orbitsystech
ID: 37767746
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!
0
 
LVL 10

Expert Comment

by:Owen Rubin
ID: 37769798
Cool. Let me know. Thanks.
0
 
LVL 1

Assisted Solution

by:orbitsystech
orbitsystech earned 0 total points
ID: 37772898
Tried MSAD Login but the darn program kept crashing and I was never able to get it set up.

I spoke with the engineer that was going to try disabling SMB2 server-side and he informed me that he tested it out and it didn't make a difference at a client site so he didn't believe it would make a difference for us either.

For the heck of it I had my own copy of OSX 10.7 so I decided to try upgrading to that on the Work computer that's been having this issue (thank you apple for no product keys).

Bam: fixed.

To make sure I wasn't imagining things I Rebooted a couple times and verified that the wireless was disabled. I also unbound the computer from the domain (active directory) and re-bound it and it's still working great. So, the problem really isn't fixed because it still very much exists in 10.6, 10.5 and 10.4 but apparently Apple fixed their crap-tastic SMB protocol in 10.7.

The problem doesn't seem to exist after the upgrade but somehow I don't feel.... successful. I'll be keeping an eye on things the next few days to see if the problem rears it's ugly head again.
0
 
LVL 10

Expert Comment

by:Owen Rubin
ID: 37775311
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.
0
 
LVL 1

Author Closing Comment

by:orbitsystech
ID: 37854915
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.
0

Featured Post

Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

Join & Write a Comment

There is a security feature on iOS devices that is nearly impenetrable when it has been activated.  This article will provide some possible solutions as well as necessary steps to take to ensure you do not end up with a locked device.
Short answer to this question: there is no effective WiFi manager in iOS devices as seen in Windows WiFi or Macbook OSx WiFi management, but this article will try and provide some amicable solutions to better suite your needs.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now