First, try starting SlickEdit (the "vs" binary) with a -sul
option to see if the "access denied" message goes away. This option disables the byte-range file locking that SlickEdit normally performs, which seems to hit the NFS locking bug under certain circumstances.
If you still continue to have issue even with the -sul
option, please post the output of the following commands (or send it to firstname.lastname@example.org
if you don't want to post it here):
On the server that exports the filesystem,
On the client machine that mounts the filesystem,
/usr/sbin/rpcinfo -p <server name>
to help us reproduce it.
Also, if the problem happens only infrequently, does it tend to happen with files of any size, or does it tend to happen with larger files?
Do you have nfslock running both on the client and the server? To check the status of nfslock, run
/sbin/service nfslock status
and check its output.
We have not been able to reproduce this problem on our end, but we are aware of this problem and are continuing to look into it.
On a general note, I would advise NOT to use 'async' option at all cost (very unlikely as it is off by default in all recent implementations of Linux NFS, but I still have to mention), and try to use TCP instead of UDP on both server and client. NFS over UDP is more susceptible to packet loss and/or network latency, so at the expense of a slight performance loss, I would recommend NFS over TCP. NFS over TCP is the default method in later versions of 2.4 and all of 2.6. If you happen to use kernel 2.4.17 or something close to that version, pay extra attention to the protocol details of your NFS service because a lot changed during that version.