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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
