Re: NooB Assitance with debugging NFSv4 client requested

[Tim Watts <t.watts@imperial.ac.uk>]

Hi Bruce,

On 13/12/10 18:55, J. Bruce Fields wrote:
> On Mon, Dec 13, 2010 at 11:43:12AM +0000, Tim Watts wrote:
>> 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.
>
> All permissions are enforced on the server side--the effect of an
> idmapper failure should just be that "ls -l" shows bad results (e.g.,
> "nobody" as the owner of every file) and that commands like "chown"
> fail.

Thanks very much for your reply.

Thanks for confirming the logic - I certainly now believe I have an 
issue with idmapd - sometimes the user will change to "nobody" and the 
group is good, and sometimes the reverse will happen.

We are using LDAP - with nscd - I might give myself a static /etc/passwd 
and /etc/groups entry to see if that makes the problem go away.

I'll run idmapd in debug plus under strace to see what's happening.


> If you're actually being prevented from performing normal filesystem
> operations, then the most likely culprit is with gssd and krb5.

I think I *may* have discovered the cause, eventually.

I have a couple of bash functions that maintain a user kerb principle 
and a root one - the root one being in /tmp/krb5cc_<uid>_root - and the 
bash function switches the env var to suit the mode I want to be in.

Seems that having two files of the form /tmp/krb5cc_<uid>* might be 
confusing something, so I have made the root one have a totally non 
conforming name to see if that was the cause.

> Might be worth filing a bug with ubuntu.

I did - it got classified under "nfs4_acl_tools"(!). I don't think 
Ubuntu are big on NFSv4 and I'm happy to try to get to the bottom of 
this, but it's pretty new to me (I've run a lot of NFSv3 before though).

> rpc.gssd debugging you've tried.  Sniffing client/server and client/kdc
> traffic with wireshark might also show some more information.

Yes - that would be worth doing.

> I dunno.  Maybe strace rpc.gssd during the failure?

Yes - might be worth doing that too.

Luckily during the failure conditions, the desktop is usable enough so I 
can at least get around and look at stuff.

Many thanks for the pointers :)

Cheers

Tim

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