On 20.07.12 10:51, Gene Heskett wrote: > On Friday 20 July 2012 10:18:49 Erik Christiansen did opine: > > Would it help if we again posted some advice on how to most easily > > change the uids on one host to match another? > > While that could I suppose be useful when the distro's involved are mix-n- > match, I fail to see the utility of it when I am uid:gid 1000 on all 4 > machines, all installed from our own 10.04-4 LTS install cd.
That's fair, since you've already done all we were suggesting. So that source of trouble has been eliminated. > Much more useful would be some real examples that all I'd need to translate > would be to my hostnames or even hardcoded addresses. To my knowledge, > there does not seem to be a way to make these services startup like a > babbling idiot and tell us what they are doing, or why they can't do it. > That would be 1000's of times more useful. True. When it's failing, what do the logfiles say? ISTR that it's one of the first places you usually look, admittedly. The nfs-kernel-server package unsurprisingly logs stuff in /var/log/kern.log, and seems to be reasonably talkative, even when things are going well. Without a hint from the logs, we're reduced to shooting in the dark, or at least through a growing cloud of BP smoke of our own making. > ATM, my /etc/exports file contains 1 non-commented line: > /home/gene/ coyote.coyote.den(rw,sync,no_subtree_check) How does your DNS respond to that hostname, if you try a "dig coyote.coyote.den", or if not, does at least "ping coyote.coyote.den " pick up the right IP address? (i.e. are we certain that the problem is in NFS?) Just for comparison, I've gotten away with nothing more than lines like this in /etc/exports: /export/share 192.168.1.0/24(rw) > On all machines with the FQDN of that machine edited in. > > Similarly, the only active line in /etc/auto.master on all machines is: > /net -hosts I've never tried autofs. In this case, it seems to be another potential source of gremlins. Your aversion to editing /etc/fstab is noted, but if we append a line to nfs mount a remote filesystem, it (a) shouldn't interfere with preceding mounts, IIRC, and (b) can be tested before shutting down, by invoking the mount command just with either the filesystem or mountpoint as argument. That will cause its /etc/fstab entry to be used for mounting, and prove the pudding. Once that works, then editing finger-fumbles have been tested, and a reboot need not be feared. (Later, autofs mounting could be tried, if desired, once NFS is known to work.) ... > When I was running pclos on this box, with its 2.6.38.8 kernel, this all > worked flawlessly except for the uid:gid problems when copying files so I > always had to become root and fix that. Ah ... so the other boxes are unchanged, and the problem ought to be on "this box". It's still a puzzle, without some logfile or cage-kicking clues. > So how do I go about making autofs and nfs-kernel-server get all mouthy so > I can see where it fails? Right now it all comes back 'OK' but doesn't > actually connect anyplace but on lathe.coyote.den, which does create a > /net/lathe subdirectory, but its empty. The /net directories are empty > after many restarts of those 2 services in /etc/init.d on the other 2 > boxes, this one and shop.coyote.den. Lappy hasn't been out of the case > locally in a month or more and ATM is not on my priority list until I need > it. Oh, not much is mounting at all? (I'd incorrectly recalled that it only gummed up after some time.) All the more reason for testing nfs without autofs. An IP-address-netmask pair, as worked for me, might also be worth trying. If you can post what happens when the abovementioned sticks are poked into the cage, we'll hopefully be a step closer to identifying the gremlins. Erik -- In 80% aller Software-, Hardware-, etc. Probleme hilft die AEG-Methode: Ausschalten, Einschalten, Geht wieder. OR In 80% of all Software-, Hardware-, etc. problems, the AEG method helps: Switch Off, Switch On, Goes again. (Hmmm ... it's better in the original language.) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
