Red Hat Bugzilla – Bug 770490
NFSv4 completely ignores idmapper
Last modified: 2012-03-22 15:30:07 EDT
Description of problem: I have solaris express 11 NFS server and linux clients. With older fedora-12 clients everything works as expected. But with fedora-16 it is broken (I have latest nfs-utils with fixed problem of reading domain from idmap.conf ) Version-Release number of selected component (if applicable): nfs-utils-1.2.5-3.fc16.x86_64 How reproducible: Steps to Reproduce: 1. create proper /etc/idmap.conf 2. start rpc.idmapd 3. mount NFSv4 share 4. ls -l on mounted directory Actual results: # rpc.idmapd -vvvvvvvvvvv -f rpc.idmapd: libnfsidmap: using domain: localdomain rpc.idmapd: libnfsidmap: Realms list: 'LOCALDOMAIN' rpc.idmapd: libnfsidmap: processing 'Method' list rpc.idmapd: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch rpc.idmapd: Expiration time is 600 seconds. after mount, all UID/GID of files shown on local machine to be 4294967294 (which differs from local nobody, nfsnobody and from remote nfsnobody). The only exceptions are files owned by IDs which has no correspondent names on remote system. (For example if I chown to particular numeric ID which does not exist on remote machine, then on client it will be shown properly) /var/lib/nfs/rpc_pipefs/nfs remains empty Expected results: when start idmapd on older F12 system, it logs new client on mount and all attempts to resolve names to ids. on F16 log remains silent. /var/lib/nfs/rpc_pipefs/nfs on F12 host if full of clntXXX directories. Additional info:
I've got a feeling the bz is the same problem: https://bugzilla.redhat.com/show_bug.cgi?id=800679 Could you also get a binary network trace using either tcpdump -s0 -w /tmp/data.pcap host <server> or tshark -w /tmp/data.pcap <server> The bzip2 the trace file: bzip2 /tmp/data.pcap
*** This bug has been marked as a duplicate of bug 800679 ***