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): autofs-4.1.3-154 How reproducible: Always Steps to Reproduce: 1. Create file maps to duplicate the map structure described above 2. Attempt to enter the submountdir directory 3. Actual Results: Error message in syslog as described above Expected Results: server:/mountpoint should be mounted on "submountdir" Two sub-automounts should be started Additional info:
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 being tested.
Created attachment 122998 [details] Attempt to fix incorect parsing when colon is not present Hi Ian, Could you test this patch please. Ian
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.