Version-Release number of selected component (if applicable): autofs-3.1.7-21 How Reproducible: always Steps to Reproduce: 1. create yp map auto.master and auto.home and configure host to read yp maps. contents of auto.master similar to "/home -rw host:/home" 2. run ypcat -k auto.home > auto.home 3. run "/etc/rc.d/init.d/autofs start" from the same location as "2" 4. run "service autofs status" notice command line someting like: Actual Results: /usr/sbin/automount /home file auto.home 5. notice errors in /var/log/messages about improper path to auto.home. Expected Results: /usr/sbin/automount /home yp auto.home Additional Information: Under no circumstances autofs startup scripts should provide maptype "file" without full name to map file. Autofs startup script gets confused by a local file auto.home and mistakenly uses it as a map file despite to a relative (e.g. not starting from "/") path.
Please post exact configuration files and log messages. thanks.
It has been two years, three months and sevearal releases between my submission and your question. I'll have to configure FC2 to use NIS and see if there are any changes. Meanwhile you can do the same. Thank you.
I believe this "bug" still exists in autofs 4.1.3. Chris, can you take a look at this? I believe we should change the following in the init script: # Handle degenerate map specifiers if [ "$maptype" = "$map" ] ; then if [ -x "$map" ]; then maptype=program elif [ -x "/etc/$map" ]; then to not look in $cwd as suggested. However, the first check should be kept, if the prefix is a /. So, if $map is /etc/foo.map, then we should still just try $map. Note that there is no reason a user couldn't put the map somewhere other than in /etc. We shouldn't restrict this. Rather, we just want to check the path given if it is an absolute path, otherwise look for the file name in /etc.
I have tested it, and the bug still exists. I'll put together a patch that will make sure that $map is a absolute address (it must start w/ a '/').
This bug has been fixed and is in autofs-4.1.3-41.
1:4.1.4-5 is available in FC4. Setting status to "CURRENTRELEASE", however if you still experience this problem after updating to our latest Fedora Core release and are still interested in Red Hat tracking the issue, and assisting in troubleshooting the problem, please feel free to provide the information requested above, and reopen the report. Thanks in advance.