OSX and Linux NFS shares
At work we had this odd problem of OSX (Leopard) clients disconnecting from our NFS file shares. The problem occurred when the clients opened the index of their mounted location. At this point the whole finder (OSX file browser) disconnected and reported “Connection interrupted”. However, the users were able to open child folders directly (e.g. /mount/folder/) which eventually made their work little bit possible, but usually within minutes they got disconnected again while doing copy jobs and such.
There are a lot of topics about OSX and NFS to find on the internet, but most of them did not help us a lot on this subject while they do claim to improve OSX mounting on different subjects, which they actually did for previous problems we had. On this article we just focus on our problem described above and the fix we used. I can’t guaranty it will work with other configurations.
Server side NFS configuration
- Debian Lenny
- Kernel 2.6.26-2-686
NFS /etc/exports:
/mnt/raiddata 192.168.1.0/24(rw,insecure,insecure_locks,no_subtree_check,root_squash, all_squash,anonuid=1000,anongid=1000)
As you can see there are a lot of options in place. This is a result of previous problems with Locked files, Write permissions etc. These server side options fixed that. This might be the cause of the problem we’re covering right now.
The OSX client fixing
We came across a specific error by looking at the system log file. This log file can be found within OSX at /var/log/system.log
The error reported:
kernel[0]: nfs server SERVER:/path: lockd not responding
To find if your clients having this same issue,try:
cat /var/log/system.log | grep nfs
The fix is quite simple. Add the nolocks option to the mount arguments. This can be done through the Directory Utility.
For manual mounts through the terminal it should be something like:
mount_nfs -P -o nolocks,nosuid server:/path /localpath
I’m not sure what the consequences are by setting this option, but it did fix our problem perfectly and our OSX clients run like a charm.
Thanks for reading.