Red Hat Bugzilla – Bug 176627
Multimounts containing multiple automounts of implicit map type fail
Last modified: 2008-08-02 19:40:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041215 Firefox/1.0 Red Hat/1.0-12.EL4
Description of problem:
Multimounts fail due to a parsing error if they contain multiple nested "sub-automounts" that don't use the "<type>:<mapname>" to explicitly indicate map type. For example, the following submount will fail:
submountdir / server:/mountpoint \
/nestedmount1 -fstype=autofs auto.nested1 \
/nestedmount2 -fstype=autofs auto.nested2
This will produce the following error when you attempt to enter "submountdir"
"nsswitch: unable to find map, auto.nested1 /nestedmount2 -fstype=autofs auto.nested2 in domain, mydomain.com"
As best I can tell, this occurs because the multimount parsing code assumes that the source for a multimount must contain a colon. As a result, it calls the internal "chunklen" function with the "expect colon" value set to true. This causes the parser to ignore all tabs and spaces, processing the remainder of the line as if it were the map source (producing the error message above).
This assumption works if the source is an actual NFS share, or if it is a sub-automount with an explicitly indicated type. It fails if the sub-automount has no explicit type.
(Note that the code to use nsswitch to find an implicit map _does_ work just fine.)
I've attached a patch that fixes this particular case. However, I suspect it will still fail on more complex multimounts that combine sub-automounts with NFS shares.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create file maps to duplicate the map structure described above
2. Attempt to enter the submountdir directory
Actual Results: Error message in syslog as described above
Expected Results: server:/mountpoint should be mounted on "submountdir"
Two sub-automounts should be started
Created attachment 122894 [details]
fix the parser to not choke on the absence of a colon in a multimount entry
After discussing this with Ian, we've agreed that the caller in question should
never set expect_colon to 1. This patch affects that change, and is currently
Created attachment 122998 [details]
Attempt to fix incorect parsing when colon is not present
Could you test this patch please.
Ian M., have you had a chance to try out Ian K.'s patch?
Ian M, any news?
Ian M., are you alive?
I'm closing this as WONTFIX, since the reporter is no longer responsive, and
because it does not seem to fit the RHEL 3.9 release criteria.