FreeBSD NFS client and Netware 6.5 NFS server

[Bob Johnson]

Message below is about a FreeBSD server I maintain.  The FreeBSD server 
is our web server.  We use NFS to talk to a Netware file server where 
most of our users' web pages are stored.  FreeBSD is 5.3, and was 
working ok with Netware 5.1 (and still is with other Netware servers). 
One of the servers was recently upgraded to Netware 6.5 and NFS is no 
longer playing nice between the two.

When something on the Netware side updates a file by copying it into 
place (e.g. using FTP [don't complain] to upload a file), the FreeBSD 
client doesn't find out that the file contents have changed until it 
does something to the file (e.g. touch or chmod).  Thus, when one of our 
users updates their web page with something like Dreamweaver, the web 
server doesn't find out about it (perhaps it eventually finds out, but 
it takes more than the several minutes we waited).

As explained in the message below, a trace of the NFS server activity 
shows that the FreeBSD client implements ls -l as a series of <ACCESS> 
operations (whatever that is) followed by an <FS STAT>, while a Solaris 
client does a series of <GET ATTR> operations (those are the Netware 
abbreviations for the operations).   The Solaris client does not exhibit 
any of these problems.  I don't know if that is meaningful with regard 
to this problem, but clearly the Solaris client is doing things very 
differently than the FreeBSD client.

Any (useful) suggestions about how to fix this?  We've tried turning 
nfs_lockd and nfs_statd on and off on the client, we've tried both NFSv2 
and NFSv3 (only v2 worked with the older Netware server), and a few 
other things that I don't remember.

One of our other servers running FreeBSD 4.7 exhibits the same problem 
with Netware 6.5 NFS.  Netware says they've tested their NFS server 
against FreeBSD 4.7 and that it works ok, so perhaps this should be 
treated as a Netware bug, but if anyone can suggest a quick way to make 
them play together it will be very much appreciated.

Thanks,


- Bob


-------- Original Message --------
Subject: netware 6.5 nfs
Date: Wed, 02 Mar 2005 15:51:31 -0500
From: Shawn
To: Bob


I've posted the following to a netware 6.5 support forum.

----------------------------------------------------------------------
POST #1
----------------------------------------------------------------------
I just upgraded a netware 5.1 server to netware 6.5 overlay CD2 and am
having problems with NFAU to a FreeBSD workstation.

On a Windows workstation connected to the netware server with a drive
mapping, if you edit files through the drive mapping (and subsequently
save them directly to the volume) you immediately see the file changes 
at the FreeBSD mount point.

However, if you edit and save the file on your local workstation and 
then copy the file over to the volume (the mapped drive), the FreeBSD 
system does not see the change in the file (I guess its NFS cache is not
updating).  If, on the FreeBSD system you touch (or chmod/chown) the 
file the cache gets updated and you see that the file has been updated.

This was not a problem with NFAU under netware 5.1.

Has anyone else seen this problem and/or have any possible things to 
look at tuning (I'm hoping someone has a cache setting to switch).  (Am 
I even explaining this so it's understandable what's happening?)

Before you ask, this is FreeBSD 5.3 (and I see that NFAU wasn't tested 
with this version)... I'm just holding out that there is something that 
can be done.


----------------------------------------------------------------------
POST #2
----------------------------------------------------------------------

Here's some more information.  Turns out it works just dandy if the 
volume gets mounted on a Solaris 8 workstation.  I've done an NFS trace 
to see what is happening differently.  The results of an 'ls' command on 
the Solaris workstation are:

100003.3.01 <GET ATTR> [TCP <SOLARIS-IP>] RStatus 0 Accept 0 NFS 0

And on the FreeBSD workstation the results are:

100003.3.04 <ACCESS> [TCP <FREEBSD-IP>] RStatus 0 Accept 0 NFS 0
100003.3.18 <FS STAT> [TCP <FREEBSD-IP>] RStatus 0 Accept 0 NFS 0

It has one 100003.3.01 or 100003.3.04 line for each file/dir in the 
directory where the 'ls' command happens... only one 100003.3.18 line 
per 'ls' command however.  So the two NFS servers are doing something
differently... just what and how to correct?