Description of problem: autofs issue with RHE3U8 autofs RPM AND RHE4U5 RPM, but problem does not exist with RHE3U7 autofs RPM. We have 2 different Linux distribution builds each one use they're own RHE version (3 and 4). Specific issue is that for this given extract from our auto.master file, not all files are seen under /ed as expected and /var/log/messages indicate an issue with the maps it won't make available. Details below: NIS-MAP ------------------------------- /ed/s3d/caspian auto.s3d_caspian /ed/s3d/barents auto.s3d_barents /ed/s2d/caspian auto.s2d_caspian /ed/s2d/barents auto.s2d_barents /ed/s3d/south auto.s3d_south /ed/s3d/north auto.s3d_north /ed/s2d/south auto.s2d_south /ed/s2d/north auto.s2d_north /ed/partners auto.partners /ed/datawork auto.datawork /ed/develop auto.develop_i2d_i3d /ed/caspian auto.caspian_i2d_i3d /ed/barents auto.barents_i2d_i3d /ed/s2data auto.develop_s2data /ed/south auto.south_i2d_i3d /ed/north auto.north_i2d_i3d /ed/data auto.ed_data /var/log/messages output with RHE3U8/RHE4U5 autofs RPM ------------------------ Oct 30 13:12:30 svgcls001 nsswitch: nsswitch: couldn't find map auto.s3d_north Oct 30 13:12:30 svgcls001 nsswitch: nsswitch: couldn't find map auto.s2d_south Oct 30 13:12:30 svgcls001 nsswitch: nsswitch: couldn't find map auto.s2d_north Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map auto.develop_i2d_i3d Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map auto.caspian_i2d_i3d Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map auto.barents_i2d_i3d Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map auto.develop_s2data Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map auto.south_i2d_i3d Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map auto.north_i2d_i3d Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map auto.ed_data Oct 30 13:12:31 svgcls001 autofs: automount startup succeeded Version-Release number of selected component (if applicable): autofs-4.1.3-168 (RHE3U7 RPM which works fine) autofs-4.1.3-186 (RHE3U8 RPM has problem) autofs-4.1.3-199 (RHE4U5 RPM has problem) How reproducible: Everytime Steps to Reproduce: 1. Install RH3U8 autofs RPM autofs-4.1.3-168 2. Stop/start autofs or reboot Actual results: # ls /ed datawork partners s2d s3d # ls /ed/s2d # ls /ed/partners group projects sinterp_p1 # ls /ed/s3d # # df -k /ed/s2d Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 231997940 8002224 212210836 4% / Expected results: With RHE3U7 RPM the following correct entry is seen: #ls /ed barents caspian data datawork develop north partners s2d s2data s3d south # ls /ed/s2d barents caspian north south Additional info: Workaround currently is to use the RHE3U7 RPM, but this is not ideal or preferred. It's a big task for us to re-organise our NIS maps, so a fix is preferred.
What does the following command show? ypcat -k auto.s3d_north Do you have the UNDERSCORETODOT variable set in /etc/sysconfig/autofs? What does the automount: line read in /etc/nsswitch.conf?
With problematic autofs installed, but still no access to this area in /ed/s2d/north: # rpm -qa | grep -i autofs autofs-4.1.3-199.3 ALWAYS PROBLEMATIC EXAMPLE # ypcat -k auto.s3d_north p10 -rw,proto=tcp,rsize=16384,wsize=16384,nosuid netapp01:/vol/vol22/ed- s3d-north-p10 # ypcat -k auto_s3d_north No such map auto_home. Reason: No such map in server's domain ONLY A FEW WORKED ALWAYS AND HAVE ENCLUDED ONE SUCH FOR COMPARISON # ypcat -k auto.ed_data develop-logs -rw,proto=tcp,rsize=16384,wsize=16384,nosuid netapp01:/vol/vol15/ed-data-develop-logs # ypcat -k auto_ed_data No such map auto_ed_data. Reason: No such map in server's domain ANOTHER EXAMPLE WHICH DOESN'T WORK BUT APPEARS SAME ENTRY IN auto.master AS ABOVE # ypcat -k auto.develop_s2data p2 -rw,nfs3,proto=tcp,rsize=16384,wsize=16384,nosuid netapp01:/vol/vol6/ed- s2data-p2 # ypcat -k auto_develop_s2data No such map auto_develop_s2data. Reason: No such map in server's domain /etc/nsswitch.conf.....automount: files nis In both occurences, the same /etc/sysconfig/autofs is used. UNDERSCORETODOT=1 Have just tested with UNDERSCORETODOT=0 and restarted autofs which has fixed the problem. Given the additional example above which appears to be constructed the same but works always, was wondering if this is still a bug. Thanks for you're help.
The only way to determine if your example is a bug is to get the output of: bash -x /etc/init.d/autofs start Then we can see what options are passed to nsswitch and to the automounter to determine the source of the map. The change in behaviour is due to a bug that was filed against autofs. The UNDERSCORETODOT variable was expected to change all underscores to dots, but it originally only converted the underscores in select few maps. Is setting UNDERSCORETODOT=0 an acceptable fix for this problem for you?
Please provide a response to comment #3.
Since you state that setting UNDERSCORE_TO_DOT to 0 fixes the problem for you (and because I can't get further response from you), I'm closing this bug.