Hi All,

I'm looking for advice on the best way to switch from wired to wireless (and back again) on the same network, but maintaining the NFS mounts.

My laptop has two NIC's - eth0 and wlan0
(Running Kubuntu Oneiric, AMD-64)

I have several NFS mounts to a NAS

My router has both wired and wireless on the same subnet (192.168.0.x) and I have the same access to resources via both eth0 and wlan0

So - my problem is this:
I'm connected on eth0, happily working away.
I turn on wlan0, pull out the cable from eth0 and move onto wireless only.
My network is fine, but the NFS mounts will hang, until I unmount them and remount.

I've tried using AutoFS, but this didn't seem to help too much.

I have the following settings in /etc/fstab

htpc:/home/htpc/Music /mnt/music nfs user,auto

I have the following in /etc/auto.mnt

music -fstype=nfs,soft --timeout=1 htpc:/home/htpc/Music/

(I've commented out the /etc/fstab entry.. I'm not running both at the same time.!!!)

So - my question is this:
What is the suggested way to deal with switching between NIC's with active NFS mounts.
If I'm doing it right - am I using the wrong options in the NFS mount.

Bump - anyone have any suggestions/advice on this?

I am re-raising this problem the OP has documented - even if it is a bit 'old'.

It has happened to me for quite some time and I have 'lived with it' but now am a bit stalled, particularly relating to NFS mounts.

It appears the only thing to do is unmount everything (or reboot, or reconnect wired) and start again.
I can appreciate [I think] what is going on, in that NFS negotiates connections on a particular NIC and/or assigned address, but NFS seems unable to re-negotiate if the NIC is taken down e.g switching from wired to wireless on the same subnet etc.

So this is probably a NFS software problem more than a network management problem as such.

Any solutions please ?


Thank you

Hmm, it's tricky but maybe not hopeless.

The problem of course that if you switch from one interface to the next (presumably with dynamic IPs), your dhcp server assigns different IP addresses, and then the new IP makes your machine look like a completely different client. Your NFS mounts are stale then.

I'm not currently in a place where I could easily try this, but here's what you could do and see if that works:

Give your eth0 a static IP. Mount the NFS areas with the "hard" option - you need to protect ongoing accesses; they need to stall until the server comes back alive.

Now shut down eth0. Do not just pull the plug, you have to release the IP address. You may have to play with this a bit because your system may try to release NFS mounts when it realizes that the interface goes down. You need to prevent this.

Now bring up your wlan0 with the same IP. Maybe, just maybe, your mounts will come back to life. When that works, you need to automate this then, but first you need to see if that works.

Let us know if that works...
mlp

I think this is the key; will have to experiment.

Another problem with NFS is that if the server is lost (shutdown by design or otherwise), then client machines with connections in use tend to hang. 'umount' options on the client fail to clear the stale connections, so for those clients, its either reboot or try 'kill off' the processes holding the connection. This is a problem for another day. I will try have a go with the above.

Thanks for the reply.
Habs

Next week I'll be back home and will be able to do some testing because I could use the same procedure for my setup as well.

There are two different ways to go about the stale mounts and stalling processes when the server goes down. It is important to understand that the "hard" option, explicit or implicit in the mount, is a *feature*. It will, by design, get processes which access the NFS area to stall. This is to protect the integrity of the data, in particular if you write stuff to NFS. This way, you can ride out interruptions in the NFS service - when the server comes back, the processes resume unaffected. Otherwise, the connection is allowed to time out, and this can lead to corrupted files when you write, and wrong data when you read.

There is an additional option "intr" (or the opposite "nointr") which controls whether or not an I/O operation in progress is allowed to react to signals. I usually do "hard,intr" as options and have the benefits of "hard" but can still manually kill the NFS-accessing process in order to allow an umount of a stale NFS mount if I know that it won't come back.

Also, you should look into auto-mounting your NFS areas. If the NFS share is being accessed, it's the same as described above, but since the area is mounted on demand only and released after a while when no longer accessed, you dramatically reduce the probability of running into a stale mount in the first place.

mlp