This may be caused by access to a single file failing but it's most likely that the remotely NFS shared directory has gone offline, been unshared, renamed or deleted. The client has been sitting there holding open the NFS handle and when it has tried to read or write something, the object has disappeared.
Try changing directory (cd) to each of the remotely mounted resources and see if you can list the file (ls) on it. If you can't, try and remount that remote NFS resource. If you can't, there's your problem.
Last edited by hicksd8; 10-16-2017 at 09:29 AM..
Reason: Amend command suggestions to lower case
If it's a reputable storage array/SAN then, no, it shouldn't happen baring power failures and the like. Dare I suggest that the network or storage team accidently did something that they shouldn't have?
The Following User Says Thank You to hicksd8 For This Useful Post:
NFS has an inherent problem. It is not very good at knowing if the mounted resource is available or not, so it depends on a response from the host providing the resource - but only after some applications asks for it.
Example NFS4 on a Solaris 10 machine used to hang shutdown when a user executed a cd to the NFS directory, and then just left the process sitting. The machine had zones (virtuals) and some NFS connections were required from zone to zone. Not a great idea.
This meant that if NFS zone1 -> zone2 and zone2 was taken down, the machine would not reboot because NFS could not figure out how close the open file, and NFS will wait for long periods of time for a resource.
You may have what amounts to a similar problem. A user on one machine has an NFS mounted directory open - the directory lives on another virtual or machine. Something happens on the remote and the local one hangs. NFS has problems, avoid it if you can. NFS can negatively affect simple commands like pwd and system calls like realpath() if the parent directory of your current directory has an external NFS mount. And that directory no long is available.
The Following User Says Thank You to jim mcnamara For This Useful Post: