I recently came across the nfsidmap -c option. I haven't thoroughly
tried to reproduce the problem but nslcd 0.9.1-1 in experimental has an
option to flush various caches. You could put
reconnect_invalidate nfsidmap
in nslcd.conf. I'm not 100% sure if this fixes the problem but can you
reproduce
Hi Arthur,
On Tue, Oct 14, 2008 at 12:18:11AM +0200, Arthur de Jong wrote:
nfs-utils-1.1.3/utils/idmapd/idmapd.c:674:
/* XXX: I don't like ignoring this error in the id-name case,
* but we've never returned it, and I need to check that the client
* can handle it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 14 Oct 2008, Patrick Schoenfeld wrote:
That does not seem to be the root of the problem. I've built nfs-utils
with these lines commented out on one of my systems and disabled the
workaround in idmapd and the problem persists.
Thanks for
retitle 500778 nss-ldapd: problem resolving groups and users with nfs4
severity 500778 important
tags 500778 + help
thanks
On Mon, 2008-10-06 at 11:42 +0200, Patrick Schoenfeld wrote:
2008/10/3 Arthur de Jong [EMAIL PROTECTED]:
Patrick, does adding Cache-Expiration = 10 to /etc/idmapd.conf in
On Mon, 2008-10-13 at 22:17 +0200, Arthur de Jong wrote:
I will try to investigate this some more but help is appreciated with
this.
I have been able to reproduce the same behaviour with nss_ldap. If you
freshly mount a filesystem while the LDAP server is unavailable the
kernel will not re-ask
Hi,
2008/10/3 Arthur de Jong [EMAIL PROTECTED]:
Patrick, does adding Cache-Expiration = 10 to /etc/idmapd.conf in the
[General] section help at all in your setup? (the correct values should
be loaded sooner)
very good. This betters the situation a lot. Its a good workaround.
Now if you'd find
Hi,
On Fri, Oct 03, 2008 at 12:18:47AM +0200, Arthur de Jong wrote:
If using nfs4 (I've been doing some reading up but still no first-hand
experience) is that if the user doesn't exist it is generally mapped to
nobody:nogroup.
right.
The mapping is done by idmapd but at some point in
(Cc-ing the nfs-utils maintainers, perhaps they have some insight that
could solve this)
On Sat, 2008-10-04 at 09:52 +0200, Patrick Schoenfeld wrote:
My guess is that name lookups are cached in idmapd. Can you check that
by restarting idmapd (/etc/init.d/nfs-common restart) the problem goes
Hi,
On Wed, Oct 01, 2008 at 10:27:04PM +0200, Arthur de Jong wrote:
Can you produce logs of nslcd? It should report whether the LDAP server
was reachable or not. If you can run nslcd with the -d option it should
report more information that will help in tracking this down.
attached is a log,
On Thu, 2008-10-02 at 10:28 +0200, Patrick Schoenfeld wrote:
attached is a log, while the problem exists.
[EMAIL PROTECTED] ~ % ls -l test
-rw-rw-r-- 1 schoenfeld nogroup 0 12. Sep 09:49 test
Interesting enough: The symptom is similar to the system behaviour, if
nslcd is _not_ running.
Package: libnss-ldapd
Severity: serious
Version: 0.6.5
Hi,
since we use libnss-ldapd we have a problem that is quiet serious for
us, as it effectively affects login and group ACLs. However we couldn't
yet track down this issue to a specific component, therefore we didn't
report it yet.
The
On Wed, 2008-10-01 at 13:11 +0200, Patrick Schoenfeld wrote:
Our setup is a mixed Windows/Linux environment with a LDAP server, for
central authentication. Linux clients use libnss-ldapd for resolution of
usernames and groups.
Could you provide some more details? Is the LDAP server on the
Hi Arthur,
On Wed, Oct 01, 2008 at 10:27:04PM +0200, Arthur de Jong wrote:
On Wed, 2008-10-01 at 13:11 +0200, Patrick Schoenfeld wrote:
Our setup is a mixed Windows/Linux environment with a LDAP server, for
central authentication. Linux clients use libnss-ldapd for resolution of
usernames
13 matches
Mail list logo
