Subject: Atalk/NFS trouble, maybe?

From: "Michael R. Jinks" <[email-masked]>
Date: Tue, 26 Sep 2000 18:58:02 -0500

Greetings.  Mysterious troubles here, hoping somebody has seen this before.

Running NetAtalk 1.4b2+asun2.1.4 on Linux, Red Hat 6.0 (buggy but we have to
upgrade other stuff first...)

We have one box doing NetAtalk which exports local filesystems and also re-
exports some NFS mounted directories.

Right now I'm aware of two users who are having this problem; others are either
working just fine or haven't complained.  The symptoms are, user has normal
access until, all of a sudden, all access goes away; errors reported by the
users are "file in use" or "permission denied".  This seems to happen when
attempting _any_ access to _any_ file.  In the case of one user, the problem
went away very briefly (no idea what coincided with the change) but then came
back.

System reboots (client and server) don't have any effect.  Copying files to 
some new location also doesn't help, although I have yet to try accessing the
same files from some other account.

.AppleDesktop and .AppleDouble directories appear to be healthy; at any rate
the user has full read/write/execute in the cases I've looked at.

The logs look like this:

Sep 26 13:39:22 kgb-fs-pc kernel: RPC: doubly enqueued task! 
Sep 26 13:39:22 kgb-fs-pc kernel: RPC: failed to add task to queue: error: -11! Sep 26 13:39:22 kgb-fs-pc kernel: statd: couldn't bind to server localhost - giving up. 
Sep 26 13:39:22 kgb-fs-pc kernel: RPC: task of released request still queued! 
Sep 26 13:39:22 kgb-fs-pc kernel: RPC: (task is on xprt_pending) 
Sep 26 13:39:22 kgb-fs-pc kernel: lockd: failed to monitor 128.135.84.79 

It's really tough to get good debugging info out of my users, but I think
that there have been NFS filesysems implicated in all the instances where
this problem has come up, and the RPC and lockd stuff would seem to support
that.  But I can go to the users' NFS-mounted filesystems and look around
just fine from a terminal session, so it's got to be more complicated than
a simple NFS hiccup.

The NFS server is a Solaris 2.7 box, in case it matters.

So, any clues?

Thanks,
-m
-- 
Michael Jinks, IB
Systems Administrator, CCCP
finger [email-masked] for public key