# nfs-utils 1.2.0 issue

## dilbot

Recently I upgraded several servers to nfs-utils 1.2.0.   Occasionally I get the following

nfs mount error:

mount -v j172:/ /j172

mount: no type was given - I'll assume nfs because of the colon

mount.nfs: timeout set for Fri Jun 12 09:40:43 2009

mount.nfs: text-based options: 'addr=192.168.12.172'

mount.nfs: mount(2): Operation not supported

mount.nfs: trying 192.168.12.172 prog 100003 vers 3 prot UDP port 2049

mount.nfs: trying 192.168.12.172 prog 100003 vers 2 prot UDP port 2049

mount.nfs: trying 192.168.12.172 prog 100003 vers 2 prot UDP port 2049

mount.nfs: mount to NFS server 'j172:/' failed: RPC Error: Program not registered

Rebooting works, but it's not a solution.  Downgrading back to nfs-utils 1.16 is a fix

which seems stable.

So I belive something is amiss in the nfs-utils 1.2.0 code.   Before I put in a bug

report, does anyone else see the same issue?

----------

## mattmatteh

any errors in dmesg or system log on the server ?  in particular, a kernel oops.

----------

## dilbot

The nfs-utils downgrade seems to have helped a bit, but the problem still happens.   

I've found that the issue happens after several hours of non-use on the nfs shared directory.  If I close all my Firefox windows then the problem no longer shows itself.    So at this point I'd say that Firfox using shared partitions (my home directory is shared, and the firefox instances are running out of that shared directory) is the key to this problem.

Anyways, the work-around is to always close Firefox before letting the system rest for several hours.

----------

## dilbot

OK - sorry for the fogginess on this, it took a while to narrow down.

I have my home directory on a server which is shared NFS to my workstation.    When the server backup routine runs, gzip takes up 99% of the CPU and the firefox processes running out of the home directory freeze.   After the backup completes, firefox is still hozed.   

So this isn't an nfs-utils problem per se (although downgrading seems to have helped).   It's a firefox freeze under NFS issue.     I haven't found an elegant way to fix this yet, so for now I'll just kill my browsers with a cron before the backup and see if future firefox upgrades fix this.

----------

## mattmatteh

home is shared on the server ? and mozilla-firefox is running on the client ?  i think firefox plays with the disk alot, i have moved .mozilla to tmpfs on my laptop that has a solid state disk.

try copying a large file, like a few gigabytes both ways and see what happens.

matt

----------

## dilbot

Since this problem only occurs consistently when Mozilla firefox windows on NFS-mounted clients are mounted when a high-stress operation (in this case a backup routine) occurs on the server, I've put in a bug report with Mozilla - Bug 500926.

Unfortunately I've mis-named this topic since originally I thought it was primarily nfs-utils related, whereas it seems to be Mozilla's operation under NFS that's the issue.

So keys for this topic should be  "Mozilla Firfox NFS client mount corruption" instead.

mattmatteh - I'll probably follow your lead and move .mozilla as a work-around.

----------

## dilbot

FWIW, I've just set up a cron to kill mozilla before the backup on the NFS server that kills the NFS link:

20 1 * * *    for a in `ps -ef |grep ozilla |grep -v grep |awk '{ print $2 }'`; do kill -9 $a; done

Seems to work fine as a work-around until Mozilla figures out why it's killing the NFS link.  Maybe

Firefox 3.5 will have a fix for this, but it's still got package masks on it.

----------

## slackline

 *dilbot wrote:*   

> Recently I upgraded several servers to nfs-utils 1.2.0.   Occasionally I get the following
> 
> nfs mount error:
> 
> ```
> ...

 

The RPC Error is usually indicative of portmap or rpcbind (depending on which you have installed) not running on the server (or possibly the client).  Perhaps worth checking what might have killed it if a reboot works (as it will have restarted it).

slack

----------

## dilbot

I'm using portmap.   It's still running on the server and client after the NFS problems arise. 

The NFS issues only occur if Firefox is being run on the client side using a home directory on the server, so I believe the way Firefox works under NFS is the real issue.   

I've lodged a bug report with the Mozilla folk on this, and they seem to be interested in it.

----------

