Bug 829344

Summary: wrong username/domain passed in nfs4 attribute requests
Product: [Fedora] Fedora Reporter: Enrico Scholz <rh-bugzilla>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: bfields, jlayton, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-06 10:46:17 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Enrico Scholz 2012-06-06 10:15:34 EDT
Description of problem:

An operation like 'chown' creates requests which do not respect the settings in /etc/idmapd.conf.  E.g. my /etc/idmapd.conf is

Verbosity = 0

Nobody-User  = nobody
Nobody-Group = nobody

Method = nsswitch

Userspace uid/gid translation is done by nslcd (LDAP).  When there is done

 chown 505 ~/foo

an SETATTR request with an FATTR4_OWNER of 'ensc@intern.sigma-chemnitz.de' is issued.  Because the NFS4 domain is SIGMA-CHEMNITZ.DE, this operation will fail.

Strange thing is, that rpc.idmapd will be called for unknown (--> nobody mapping) users only.  E.g. 'strace -f -p <pidof-idmapd>' shows no activity for 'chown <valid-uid>' operations but for invalid uids only.  I see a connection to 'nslcd' during the chown(2) syscall but can not determine the source ('netstat' reports pid 0).

GETATTR responses from the server are containing expected owner values like 'ensc@SIGMA-CHEMNITZ.DE' which are mapped correctly on the client.

Server is an RHEL6 machine, client an F17 one (F16 was fine). Shares are mounted by 

...:/home/ /home nfs4 comment=systemd.automount,exec,nodev,nosuid,rw,sec=krb5i,posix,nointr

Version-Release number of selected component (if applicable):

Comment 1 Enrico Scholz 2012-06-06 10:46:17 EDT
sorry; reposted bug because I got a 'proxy error'

*** This bug has been marked as a duplicate of bug 829362 ***