[PlanetCCRMA] NFS client trouble with my ccrma box

Mon Mar 14 17:35:02 2005

--=-OTihGseLxEqh9k0tG6MB
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi,

I have a debian server with NFS share, and two FC3 clients, one vanilla
FC3 and one ccrma.  I keep both relatively up to date, i probably update
each box weekly.

On the vanilla box I have no problems accessing the share. 

On the ccrma box I am having a lot of problems accessing the share.

The cat5 running between these machine is probably not over 20 yards,
and I can always ping the server fine from either box.

Sometimes I transfer large files from my ccrma box onto the share.  It
is not typical that these files are >4 GB.  Sometimes I leave the share
mounted for long periods of time with files open or terminal window
open. 

The problem arises when the terminal window quits responding to requests
to access that share.  If I perform 'umount /mnt/pubshare -f' it just
says "device or resource busy" or something to that effect, and I am
unable to unmount the share.  There are no open apps that I can see that
are using part of the mounted resource, and I am not in that directory
when I try to unmount.  If I perform 'fuser -v /mnt/pubshare' it hangs.
At that point, running 'umount' from a different terminal will release
the hang, but it will complain of Input/output error rather than giving
me result of fuser, and it still will not let me umount.

Meanwhile from the other FC3 box the NFS share is responding just
fine.  

Any ideas?  Is there anything about the ccrma setup that should make
this situation different from my vanilla FC3?  Is there some
troubleshooting I can do, or some log file that will show the problem I
am having with the nfs share?  if I run nfsstat, the output looks
normal, even when the box is having the connection problem.  

The only way out for now is to reboot.  Any ideas appreciated.

Thanks!

--=-OTihGseLxEqh9k0tG6MB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
 <META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2">
</HEAD>
<BODY>
Hi, 
 
I have a debian server with NFS share, and two FC3 clients, one vanilla FC3 and one ccrma.&nbsp; I keep both relatively up to date, i probably update each box weekly. 
 
On the vanilla box I have no problems accessing the share. 
 
On the ccrma box I am having a lot of problems accessing the share. 
 
The cat5 running between these machine is probably not over 20 yards, and I can always ping the server fine from either box. 
 
Sometimes I transfer large files from my ccrma box onto the share.&nbsp; It is not typical that these files are &gt;4 GB.&nbsp; Sometimes I leave the share mounted for long periods of time with files open or terminal window open. 
 
The problem arises when the terminal window quits responding to requests to access that share.&nbsp; If I perform 'umount /mnt/pubshare -f' it just says &quot;device or resource busy&quot; or something to that effect, and I am unable to unmount the share.&nbsp; There are no open apps that I can see that are using part of the mounted resource, and I am not in that directory when I try to unmount.&nbsp; If I perform 'fuser -v /mnt/pubshare' it hangs.&nbsp; At that point, running 'umount' from a different terminal will release the hang, but it will complain of Input/output error rather than giving me result of fuser, and it still will not let me umount. 
 
Meanwhile from the other FC3 box the NFS share is responding just fine.&nbsp; 
 
Any ideas?&nbsp; Is there anything about the ccrma setup that should make this situation different from my vanilla FC3?&nbsp; Is there some troubleshooting I can do, or some log file that will show the problem I am having with the nfs share?&nbsp; if I run nfsstat, the output looks normal, even when the box is having the connection problem.&nbsp; 
 
The only way out for now is to reboot.&nbsp; Any ideas appreciated. 
 
Thanks!
</BODY>
</HTML>

--=-OTihGseLxEqh9k0tG6MB--