The usual fix for this is to re-export or restart nfs services from the server side. You could try unmount -f to force the mount point to unmount or reboot the client. It gets harder when multiple users are online. If someone has a home directory or a remote shell open using a directory under the nfs mount root, good luck fixing it on the fly. The worst situation is where two NFS file systems are mounted in a parent-child relationship.

What if there’s no open file to be found, then what? If you were looking for some sort of media file, it might be easy to use a memory based distro with tools like photorec

Make sure a firewall rule isn’t blocking NFS. If NFS is running on the server and clients _can_ mount, but it’s just really slow, then things get a little hairly. You can’t just look for a problem on a client or a fix a misconfigured server. You’ll have to look at the whole ball of wax… If MTU mismatch doesn’t seem to be a problem, try going the other way and increasing the MTU size. Use the traceroute command to look for unexpected routing hops or delays.

Opportunistic locking is part of the Windows client file caching mechanism. Samba implements opportunistic locking as a server-side component of the client caching mechanism. Samba/CIFS doesn’t play nice with NFS, so if you’re in a mixed environment where some windows machines access and modify the same files that Linux or Solaris touch through NFS, then disable the oplocks. This is important for things like database files to avoid corruption!

This lets you access your Linux home directory and local DVD drive from Windows without having to set up additional cifs/nfs mounts. My home directory is an NFS mount from another server, so you should be able to access *any* file system that is available on your Linux side.

RAID storage has come down in price in a very short period of time. Is there really any point to spending tens of thousands for small workgroups?