linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Watts <t.watts@imperial.ac.uk>
To: linux-nfs@vger.kernel.org
Subject: Re: NooB Assitance with debugging NFSv4 client requested
Date: Mon, 13 Dec 2010 11:43:12 +0000	[thread overview]
Message-ID: <4D0606D0.4010702@imperial.ac.uk> (raw)
In-Reply-To: <4D05F3E2.6090902@imperial.ac.uk>

Hmm,

Wonder if this is a clue (not noticed this before, but running idmapd in 
the foreground, it just whined):

rpc.idmapd: nfscb: read(/var/lib/nfs/rpc_pipefs/nfs/clnt0/idmap): No 
such file or directory

(Repeated several times).

I'm veering towards this issue being an idmap problem.

Cheers

tim

On 13/12/10 10:22, Tim Watts wrote:
> Bump - anyone :)
>
> Please note - I'm not requesting anyone fix a deeply obscure problem.
> I'm a sysadmin - I'd just be really grateful for some pointers to help
> me continue debugging this myself...
>
> Ta,
>
> Tim
>
> On 10/12/10 15:43, Tim Watts wrote:
>> Hi,
>>
>> I have an NFSv4 client set up on Ubuntu 10.04.1 LTS x86. The NFSv4
>> server is running Centos 5.5 and we use MIT kerberos and LDAP for
>> users/groups. This seems to work well with Centos 5.5 clients
>>
>> All works fine with my Ubuntu client, except after a while my client
>> acts like it loses its authentication - symptom: home directory mount
>> drops to "nobody" - I see the mount as "other" - no write access, can
>> read files that have world read bit set etc.
>>
>> This can happen anytime between 48 hours and 2 hours after a full client
>> reboot. It seems to be triggered by active use of thunderbird via the
>> NFSv4 mounted home dir which suggests it may be load sensitive.
>>
>> When it happens, if I unmount my home dir (killing the desktop of
>> course) , then remount the fault is cleared and I can work again.
>>
>> What doesn't work is just doing a kinit -f or restarting idmapd or gssd.
>>
>> I have run rpc.gssd in foreground debug mode and that doesn't say much
>> during the problem times, ditto idmapd. We are using openldap for passwd
>> and group lookups cached locally with nscd.
>>
>> I have tried upping kernel debugging:
>>
>> rpcdebug -m nfs -s vfs dircache lookupcache pagecache proc xdr file root
>> callback client mount all
>>
>> but I'm not sure what I'm looking for.
>>
>> The symptoms feel like the kernel is losing the ticket or timing it out
>> or possibly the ID mapping is failing - is there any way to examining
>> the state of the kernel ticket cache or anything else I could be looking
>> for?
>>
>> I am tempted to say this is a bug, possibly in the Ubuntu build, but I
>> would like to investigate further.
>>
>> Any pointers much appreciated as to how I might isolate the fault
>> further.
>>
>> Cheers
>>
>> Tim
>
>


-- 
Tim Watts
Linux Sysadmin, High Energy Physics, Imperial College London
Tel: 020 759 47809

  reply	other threads:[~2010-12-13 11:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-10 15:43 NooB Assitance with debugging NFSv4 client requested Tim Watts
     [not found] ` <4D024A8E.50407-AQ/gCgVxFfnQzY9nttDBhA@public.gmane.org>
2010-12-13 10:22   ` Tim Watts
2010-12-13 11:43     ` Tim Watts [this message]
2010-12-13 18:55       ` J. Bruce Fields
2010-12-13 19:15         ` Tim Watts
2010-12-16 22:03 ` Tim Watts
     [not found]   ` <4D0A8CC9.9050306-AQ/gCgVxFfnQzY9nttDBhA@public.gmane.org>
2010-12-17 19:16     ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D0606D0.4010702@imperial.ac.uk \
    --to=t.watts@imperial.ac.uk \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).