problem with NFS mount

[Bunty....]

hi buddies,
I am facing one problem.
there are two device - hp server & snap drive.

we had mounted a directory of snap drive to hp server's directory.

when i give bdf:
10.10.1.19:/bunty /apps/oracle/data

but now we changed the IP of snap drive i.e.10.10.1.20

i am not able to mount that drive.
please suggest

i have updated /etc/fstab file with new IP address then i give:
# mount -a

NFS getattr failed for server 10.10.1.19: RPC: Timed out

it is still showing the old ip address.

Please suggest what to do

[Chan 007 · Accepted solution]

1. Update your /etc/hosts file on both system with new IP

2. on the NFS server once again run the exportfs -a. If needed you need to change the /etc/export file and run the exportfs command.

3. run mount -a on the targer server.

[Patrick Wallek]

Well, you need to change the IP address on the HP-UX server. Check your /etc/fstab file for that entry and modify it if necessary.

[John Waller]

Unfortunatly you needed to umount the filesystem before you changed the IP address of your snap drive and your fstab entry. If possible a reboot of your hp server would resolve the issue baring that, rechanged the IP address of your snap drive back to .19 umount /bunty/apps/oracle/data, change snap drive back to .20 and mount -a to remount.

[John Waller]

Unfortunatly you needed to umount the filesystem before you changed the IP address of your snap drive and your fstab entry. If possible a reboot of your hp server would resolve the issue baring that, rechange the IP address of your snap drive back to .19 umount /bunty/apps/oracle/data, change snap drive to .20 and mount -a to remount.

[Deoncia Grayson_1]

You should first check to make sure the /etc/hosts file has been updated first to reflect the new ip address for the server.

NFS Mounting a remote filesystem on a local disk using the default TCP
mounts from HP-UX 11.11 NFS client gives the following error:

NFS getatter failed for server {hostname} : RPC(Unknown failure)

The mounts fail.



RESOLUTION

The error indicates a problem with the TCP port for NFS between the
NFS client and the NFS server.

Use the following diagnostic commands to determine if a process is
using the port that is needed for the NFS mount over TCP:


1. Use the ping command against the NFS Server name or IP address.
If it does not respond, network connectivity is the reason for the
failure.

2. Use rpcinfo -t server program command


# rpcinfo -t nfs_server 100005 ( 100005 is the program for rpc.mountd )
rogram 100005 version 1 ready and waiting
rpcinfo: RPC: Program/version mismatch; low version = 1, high version = 3
program 100005 version 2 is not available
program 100005 version 3 ready and waiting

# rpcinfo -t nfs_server 100003 ( 100003 is the program number for nfs )
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting


If this generates an error, then there is likely a problem on
the NFS Server side, or setup. Consult the NFS debugging
document NETUXKBRC00006283 for tips.

3. Use netstat -an|grep 2049|grep xxx.yyy
where xxx.yyy=last few digits of the IP address of the NFS Server.
If you see a TCP socket from the client to the NFS Server being
stuck in a "CLOSE_WAIT" or "FIN_WAIT" status, then that indicates
the TCP socket being used for NFS communciations to that NFS Server
is hung. Unfortunately,the present design of HP-UX 11.11 NFS Client
does not select another socket for the same NFS server IP address.

Example:
hp-clnt #netstat -an|grep 2049 | grep 192.168.1.1

tcp 0 0 192.168.100.100.547 192.168.1.1.2049 CLOSE_WAIT

The following workarounds can be tried:

1. Try using another IP address from the NFS Server, if available, in the
mount command, in place of the server name. For example:

mount -osoft 192.168.200.1:/export/mnt /mnt

2. Try specifying UDP mounts until the system can be rebooted. To do this
add the proto=udp to the mount option string. For example:

mount -osoft,proto=udp server:/export/mnt /mnt

Where "server" is the name of the NFS Server.

3. Reboot to clear the port, and go back to using TCP mounts.
--------------------------------------------------------------------------

[Bunty....]

#umount /apps/oracle/date
nfs umount: inform_server: 10.10.1.19:/bunty server not responding: RPC: Rpcbind failure - RPC: Timed out

this is the error now

i am tring to unmount then mount

[Geoff Wild]

More then likely you will need to reboot :(

You could try stop/start NFS on the client server:

/sbin/init.d/nfs.client stop

/sbin/init.d/nfs.client start

If it still doesn't unmount - then I'm pretty sure you will have to reboot client server...


Rgds...Geoff

[Dave Olker]

Hi Bunty,

Can you tell me what OS the NFS client system is running? If it is HP-UX 11i v2 (i.e. 11.23) you can use the "forcible" unmount command to eliminate this filesystem:

# umount -f

That will remove the old mount point from the list of mounted filesystems without requiring a reboot.

One other thing you could try would be to add a virtual IP address on the NFS server. I don't know if this is possible on a "snap" drive, but if you could temporarily add back the 10.10.1.19 address as a secondary virtual addresss (in HP-UX this would be like lan0:1) and get that server to respond to 10.10.1.19 again then you may be able to unmount the filesystem successfully and then remove the virtual IP address.

Again, I don't know if adding another IP to the server is a possibility, but if you're running 11.23 on the client the forcible unmount is a definite possibility.

Regards,

Dave

[Geoff Wild]

Dave- thanks for the info on the -f option - didn't know that - so I trolled over to doc.hp.com and also found this doc (link to specific chapter on "Common Problems with NFS"):

http://docs.hp.com/en/5991-1811/ch08s01.html

Rgds...Geoff

[Dave Olker]

Geoff,

Happy to help spread the word about new NFS features.

I've written a technical paper on techniques you can use to forcibly unmount NFS filesystems on clients running operating systems that *don't* support the -f umount option. The link to that paper is:

http://docs.hp.com/en/3929/ForciblyUnmountingNFSFilesystems.pdf

Might be interesting reading for folks who haven't yet updated to 11i v2.

Regards,

Dave