Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

We're at a university in a lab trying to create an NFS share that can be shared between OS X and Ubuntu machines. This problem has been driving my supervisor and I crazy for the past few days - posting here because we're at wits' end.

I'll try and outline the situation as best I can:

  • NFS daemon (1:1.2.5-3ubuntu3.1) is running on an Ubuntu server 12.04
  • The server setup (/etc/exports) looks like so:

    /export -rw,fsid=0,no_subtree_check client.computer.name
    /export/data -rw,async,subtree_check,all_squash,anonuid=2000,anongid=2000 client.computer.name
    /export/moredata -rw,async,subtree_check client.computer.name
    
  • share /data and /moredata have successfully been mounted on Ubuntu machines without problems using the following command:

    sudo mount server:/data /srv/data
    
  • On certain Mac OS X machines, ones running Lion or Snow Leopard, the mounts all work as normal but require modifications to the mount command due to some issues that I think are irrelevant to the problem at hand

    sudo mount -t nfs -o resvport,vers=4,proto=tcp,port=2049 server:/data /Volumes/data
    
  • On two separate machines running OS X 10.8 (latest version of Mountain Lion) however, there are major problems.

  • About half the time, the NFS share mounts fine on my iMac running OS X 10.8 but my computer grinds to a halt and even running an 'ls -la' on the server directory takes minutes to start. Once the server has mounted, even running ls on local directories has the same effect!

The other half of the time, the computer grinds to a halt during the mounting process.

  • edit Spotlight indexing is not an issue as the mount point is added to the spotlight exclusion list.

Also, running activity monitor, or 'top' yields no insight, nothing is taking more than 10% processing power, and there is plenty of available RAM.

How can I debug this? What logs are useful to interrogate?

** Updates **

  • rpcinfo log before and after mounting

http://pastebin.com/FZUxbK1s

  • Here are some interesting log results during the mounting of the share:

http://pastebin.com/yd6JEH10

This is the message that seems more alarming

2013-01-11 12:27:49.572191 PST - 348.1506 - Client: mount_nfs, UID: 0, EUID: 0, GID: 0, EGID: 0
2013-01-11 12:27:49.572191 PST - 348.1506, Module: SystemCache - Invalid name (null) for KAUTH_EXTLOOKUP_VALID_PW/GRNAM
share|improve this question
    
Would you like to keep this on SuperUser or on Ask Different? Unless you want to craft things so each is different / targeted for the different sites, it's best to have one question on the network. –  bmike Jan 7 '13 at 0:13
    
I'll keep it here since there are already three votes here. Sorry, didnt realize the communities were linked that much. –  Firas Jan 7 '13 at 2:59
add comment

4 Answers

Try adding nolocks and locallocks to those specific machine mounts.

credits: http://hardforum.com/showthread.php?p=1039476929

share|improve this answer
    
Thank you for this, this looked/looks extremely promising, I have been trying to mount the share with the two options on and off to see if it makes a difference. I'll report here once I have some statistics. –  Firas Jan 9 '13 at 21:33
    
I tried mounting with this option on and off, and found that this is likely not the issue as the first time it did not work, second time the mount was fine, third didn't work and fourth did work. :-( –  Firas Jan 11 '13 at 1:11
add comment

It is possible that spotlight (OS X index/search service) is trying to index the new mount points, which means trying to go through the whole directory structure and every single files in it. You can disable indexing on those mount point doing following

  1. Open System Preferences
  2. Click Spotlight
  3. Click Privacy
  4. Click + to add NFS mount point into exclusion list.
share|improve this answer
    
The mount point is already in the exclusion list as we thought this might be the causes earlier in our troubleshooting process. Sorry I forgot to mention that. I'll edit the original post to reflect this. Thanks for the reply –  Firas Jan 9 '13 at 8:27
1  
I assume you have no time machine running or also excluded the nfs mount point, right? –  John Siu Jan 9 '13 at 16:21
    
Please run rpcinfo on nfs server before and after OS X connection and add to question. –  John Siu Jan 9 '13 at 16:23
    
Time machine was disabled while I troubleshoot this. Posting rpcinfo logs above. –  Firas Jan 9 '13 at 21:30
    
Here is the log: pastebin.com/FZUxbK1s –  Firas Jan 11 '13 at 1:13
show 1 more comment

It's an IO bottleneck, not a CPU bottleneck. This is why you are not seeing high percentage usage with a task manager.

This points me to think that there might be issues with your network connection to the NFS server. Perhaps routers, hubs, or switches, the in-between devices may be dropping your packets (had this issue with both FTP and SVN on different occasions with different hardware). If you can, I would try setting a static IP for both server and iMac, and use one good, tested ethernet cable to connect them directly together. See how it performs then.

If the problem still persists, perhaps there is 3rd party NFS mounting software you can use on the Mac, that would pin-point if it is Apples NFS implementation causing issues.

Perhaps try installing Linux in a virtual machine on the Mac and see if you can connect to the NFS on that. That would rule out any sort of hardware issues on the iMac side.

Tools:

  • Look into the terminal application "iotop" command on both Mac and Linux side.
  • Wireshark, I don't use this much, but perhaps it will help.
share|improve this answer
    
Thanks for this! I'll start looking into your suggestions, see above for the results of tail -f /var/log/*log during the mounting process, does anything pop out w/rt to IO? –  Firas Jan 11 '13 at 20:50
add comment

You could also try mounting it using autofs (see here or here for a technical white paper from Apple).

That way, the share is only mounted when accessed and automatically unmounted when not in use. If you make sure to add the soft option so the system does not hang waiting for the share to respond, you might have solved your problem.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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