Anders Boström wrote:
> Sorry for the late respons... I've got time to test this again, and it
> is indeed a domain-problem. However, I don't get any nfsidmap-messages
> in the client syslog, but I do in the server. If I reconfigure my
> client idmapd.conf to 'Domain = localdomain' it works as expe
> "JH" == Jamie Heilman writes:
JH> Anders Boström wrote:
>> > "SW" == Stephan Windmüller writes:
>>
SW> On 23.10.2011 13:49, Jamie Heilman wrote:
>> >> Chances are you all have your nfsidmap Domain mismatched between
>> >> client and server; check your user.* syslog logs on the c
Anders Boström wrote:
> > "SW" == Stephan Windmüller writes:
>
> SW> On 23.10.2011 13:49, Jamie Heilman wrote:
> >> Chances are you all have your nfsidmap Domain mismatched between
> >> client and server; check your user.* syslog logs on the client for
> >> messages like: nfsidmap: nss_ge
Stephan Windmüller wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 24.10.2011 00:58, Jamie Heilman wrote:
>
> >> In my configuration both domains (client and server) are
> >> correctly set, but this is not the issue: passwd and group data
> >> is fetched from ldap as set in nsswit
> "SW" == Stephan Windmüller writes:
SW> On 23.10.2011 13:49, Jamie Heilman wrote:
>> Chances are you all have your nfsidmap Domain mismatched between
>> client and server; check your user.* syslog logs on the client for
>> messages like: nfsidmap: nss_getpwnam: name 'foo@bar' does not ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24.10.2011 00:58, Jamie Heilman wrote:
>> In my configuration both domains (client and server) are
>> correctly set, but this is not the issue: passwd and group data
>> is fetched from ldap as set in nsswitch.conf, but idmapd does not
>> seem to re
Stephan Windmüller wrote:
> On 23.10.2011 13:49, Jamie Heilman wrote:
>
> > Chances are you all have your nfsidmap Domain mismatched between
> > client and server; check your user.* syslog logs on the client for
> > messages like: nfsidmap: nss_getpwnam: name 'foo@bar' does not map
> > into domain
Chances are you all have your nfsidmap Domain mismatched between
client and server
That was it! I would never have discovered that without help.
I guess this is part of the charm of running Sid :)
Thank you!
Nils
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a su
On 23.10.2011 13:49, Jamie Heilman wrote:
> Chances are you all have your nfsidmap Domain mismatched between
> client and server; check your user.* syslog logs on the client for
> messages like: nfsidmap: nss_getpwnam: name 'foo@bar' does not map
> into domain 'baz'
In my configuration both domai
Chances are you all have your nfsidmap Domain mismatched between
client and server; check your user.* syslog logs on the client for
messages like: nfsidmap: nss_getpwnam: name 'foo@bar' does not map
into domain 'baz'
The old defaults for rpc.idmapd pre 1:1.2.5-1 didn't make much sense,
(see bug #6
Hi!
I can confirm this problem with nfs-common 1:1.2.5-2, NFSv4 and
amd64. uid/gid is mapped to nobody/nogroup. Downgrade to 1:1.2.4-1
solves the problem. Running rpc.idmapd with -vvv don't show any errors
or strange messages.
/ Anders
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@list
> After upgrade to nfs-common 1:1.2.5-2 I noticed that uid/gid's are
> displayed as 'nobody' and 'nogroup' respectively. This is the case
> checking with both Nautilus and terminal. Downgrading to 1:1.2.4-1
> from Testing fixes the problem.
Same problem here, but with 1:1.2.2-4 from squeeze.
-
Package: nfs-common
Version: 1:1.2.5-2
Severity: important
After upgrade to nfs-common 1:1.2.5-2 I noticed that uid/gid's are displayed as
'nobody' and 'nogroup' respectively. This is the case checking with both
Nautilus and terminal.
Downgrading to 1:1.2.4-1 from Testing fixes the problem.
I am
13 matches
Mail list logo
