I have a Windows NFS server and several CentOS linux servers which were mounting volumes from it. The Windows server moved to a new network and even though DNS works and the NFS mount was mounted by hostname, it appears the NFS client also makes note of the ipaddr value, which is no longer valid. This causes the typical hanging mounts, df, issues one would expect. How do I resolve this retroactively?
If the IP address has changed then you'll likely need to restart the NFS clients and/or run the
umount command explicitly releasing the mounted service. This may not be able to complete though, with the original NFS service is now gone.
The only other approach that I was able to find was this one, written up in this Linux Journal article titled: How-To: Release Stuck NFS Mounts without a Reboot. I've never used this approach and until today never heard of this method but it does sound feasible in looking through it.
Also I believe you may run into issues depending on whether the NFS mount was mounted with intr/nointr. You can read more about this feature switch in the NFS man page,
intr / nointr Selects whether to allow signals to interrupt file operations on this mount point. If neither option is specified (or if nointr is specified), signals do not interrupt NFS file operations. If intr is specified, system calls return EINTR if an in-progress NFS operation is interrupted by a signal. Using the intr option is preferred to using the soft option because it is significantly less likely to result in data corruption. The intr / nointr mount option is deprecated after kernel 2.6.25. Only SIGKILL can interrupt a pending NFS operation on these kernels, and if specified, this mount option is ignored to provide backwards compatibility with older kernels.
This Post has steps that have worked for me. In a nutshell:
- Assign Old IP of NFS server to an alias.
ifconfig eth0:fakenfs Old_IP netmask xxx.xxx.xxx.xxx
umount -l /mount
- bring down the alias:
ifconfig eth0:fakenfs down
- Mount the NFS share again: