Folks, I have tracked down the source of this problem. This is due to the fact that the following order of init scripts occurs:
S18rpcidmapd ... S25netfs ... S27ypbind I happen have a mount in my /etc/fstab which does an NFS mount of a filesystem owned by my uid/gid. This occurs in the netfs script before ypbind is run so that my uid and gid get cached as 'nobody'. I am still considering how I will best work around this, but it will be a problem for anyone who uses NIS and happens to mount (as NFSv4) a directory which should later get its true mapping via NIS. Andy On Jun 25, 2012, at 10:30 AM, Matthias Saou wrote: > *very* interesting to know, thanks for sharing what you've found! > > Matthias > > On Mon, 25 Jun 2012 15:04:58 +0000 > "Feldt, Andrew N." <[email protected]> wrote: > >> Ian, >> >> I went to verify the response I originally began for this >> message and used other accounts than my own for testing >> ls -l /home/username (before, I just used mine because >> I first tested with that and found this problem). >> >> To my surprise, I found that the id mapping works fine >> for all of our user accounts *except* mine! This >> account has uid and gid of 900. I have other accounts >> with numbers below this, so it is not some minimum >> cutoff. I also have other accounts in my group >> (all with gid 900) which map the username properly >> but the gid for 900 is still shown as 'nobody' for >> them (as expected since that is how it is shown for >> my account. >> >> I discovered a change in nfs-utils which provides the >> new command nfsidmap (see its man page for details). >> I find that, if I run 'nfsidmap -c' after booting >> the problem is resolved. It appears that there has >> been a change in the way ids are mapped so that they >> are cached. And, something in our boot process must >> access my uid/gid (e.g. my account) before ypbind is >> run and so these get cached as 'nobody'. However, >> this begs the question of the startup ordering of >> rpcidmapd, ypbind and autofs since I have no >> special script of any sort that is run in between >> rpcidmapd and autofs. I will try to dig into this >> further, but we should not have to work around this >> caching issue. >> >> Andy >> >> On Jun 24, 2012, at 6:57 PM, Ian Mortimer wrote: >> >>> On Fri, 2012-06-22 at 17:22 +0000, Feldt, Andrew N. wrote: >>> >>>> Thanks for the info. Unfortunately, this does not help the >>>> idmapper problem. And, we had no problem actually automounting >>>> the file systems. The only problem is in the id mapping. >>> >>> So is the problem with autofs or with rpcidmapd? Every time I've >>> seen this, the fix has been: >>> >>> umount file_system >>> service rpcidmapd restart >>> mount file_system >>> >>> >>> -- >>> Ian >>> >>> _______________________________________________ >>> rhelv6-list mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/rhelv6-list >> >> >> _______________________________________________ >> rhelv6-list mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/rhelv6-list > > > > -- > Matthias Saou ██ ██ > ██ ██ > Web: http://matthias.saou.eu/ ██████████████ > Mail/XMPP: [email protected] ████ ██████ ████ > ██████████████████████ > GPG: 4096R/E755CC63 ██ ██████████████ ██ > 8D91 7E2E F048 9C9C 46AF ██ ██ ██ ██ > 21A9 7A51 7B82 E755 CC63 ████ ████ > > _______________________________________________ > rhelv6-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv6-list Andy Feldt Senior System Support Programmer Affiliate Assistant Professor Homer L. Dodge Department of Physics & Astronomy The University of Oklahoma _______________________________________________ rhelv6-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv6-list
