Red Hat Bugzilla – Bug 1269017
variable expansion does not occur
Last modified: 2016-07-19 16:14:56 EDT
Created attachment 1080131 [details]
LDIF for automount to test with
Description of problem: using $USER in automountKey values does not expand on target system, and literal path of $USER is created
Version-Release number of selected component (if applicable): autofs-5.1.0-12.fc22.x86_64
How reproducible: very
Steps to Reproduce:
1. load automountMap schema into LDAP
2. populate LDAP with automountMapName and automountKey entries and values
3. use autofs via LDAP (or SSSD pointed to LDAP) to mount NFS shares (automount -dfvvv)
4. find $USER references in output and in filesystem
Actual results: mountpoints for expanded variable do not exist
Expected results: mountpoints for expanded variable should exist
Additional info: attached LDIF includes automountMapName and automountKey entries and values that work (auto.shares, auto.direct) as well as entries and values that dont work (auto.indirect)
I'm afraid I'm struggling to work out what it is your trying
to say here.
The ldap ldif you've provided looks like it has a number of
entries that are invalid for a couple of different reasons so
maybe you should start by describing what you're trying to
achieve and how you expect this to function.
Basically, I think you've made a number of assumptions that
the ldif provided is intended to provide working and non-working mappings. by simply changing a few minor details, i am able to demonstrate the variable expansion issue or have my automounts work.
the desired result is to have automount mappings use variables such as $USER, so that /home/user1/Music, or /home/user2/Music for example is mounted without having to be hardcoded or a direct mapping. i intend on having the $USER variable expanded so the mapping correlates to the value of the variable, and is not taken literally.
(In reply to bpk678 from comment #2)
> the ldif provided is intended to provide working and non-working mappings.
> by simply changing a few minor details, i am able to demonstrate the
> variable expansion issue or have my automounts work.
> the desired result is to have automount mappings use variables such as
> $USER, so that /home/user1/Music, or /home/user2/Music for example is
> mounted without having to be hardcoded or a direct mapping. i intend on
> having the $USER variable expanded so the mapping correlates to the value of
> the variable, and is not taken literally.
That's one of the problems with the ldif.
It's not possible to use variables in the key and never has been.
It doesn't make sense to use this in indirect maps as this is
meant to done using the standard wildcard substitution.
For example an indirect map that provides /home/$USER mount points
would have a master map entry like (and as this is an example you
will need to translate it ldap, where the wildcard is usually /
not *, although IIRC * should work too, not sure):
and /etc/auto.home would have:
where & requests the key that has matched the wildcard be used
as its replacement.
your example does not make sense. * and & refer to each other, per the man page. if you wildcard the key with a *, and use & in the location, then both are substituted with the same value. i dont see how this relates to what i am trying to accomplish.
moreover, the man page explicitly indicates that variable substitution works in both the key and location fields. the $USER variable is expected to expand based on the user requesting the mount when used in either the key or the location field, when it does not actually do so.
i dont want to mount a users home dir with this configuration. i want to mount a directory under a users home dir, regardless of anything to do with where or how the users home dir is mounted, etc.
(In reply to bpk678 from comment #4)
> your example does not make sense. * and & refer to each other, per the man
> page. if you wildcard the key with a *, and use & in the location, then
> both are substituted with the same value. i dont see how this relates to
> what i am trying to accomplish.
Then I don't understand what it is your trying to accomplish.
You can use the macros in the location field, just not the key
The keys of an indirect map are a single directory component,
not absolute or relative paths.
If you use the multi-mount syntax you can do things like:
* / server:/path/& \
and the offsets under the root offset ("/") would be
mounted on access.
> moreover, the man page explicitly indicates that variable substitution works
> in both the key and location fields. the $USER variable is expected to
> expand based on the user requesting the mount when used in either the key or
> the location field, when it does not actually do so.
The man page of F22 doesn't say that, it says:
The following special variables will be substituted
in the location field of an auto‐mounter map entry if
prefixed with $ as customary from shell scripts (curly
braces can be used to separate the field name):
ARCH Architecture (uname -m)
CPU Processor Type
HOST Hostname (uname -n)
OSNAME Operating System (uname -s)
OSREL Release of OS (uname -r)
OSVERS Version of OS (uname -v)
autofs provides additional variables that are set based
on the user requesting the mount:
USER The user login name
UID The user login ID
GROUP The user group name
GID The user group ID
HOME The user home directory
SHOST Short hostname (domain part removed if present)
Additional entries can be defined with the -Dvariable=Value
map-option to automount(8).
Map entries consist of <key, location> pairs so that says that
macro translation will be done only on the location field and
not the key field.
The problem with using map keys with macro substitution in indirect
mount maps is that to do it the entire map would need to be scanned
for every lookup and each key checked to see if it's a macro then
translated if it is before attempting to match the key to the
Scanning the entire map is a performance killer for maps that have
a large number of keys and can be a problem or maps with even a
relatively small number of entries if there are frequent lookups.
For direct mount maps the keys are absolute paths and each key
in a direct map must be mounted as an automount trigger before
any mount requests are received.
That means that direct map keys could not have macros that don't
have a known value at the time the trigger is mounted.
Given that the user id that is making the mount request is set
at the time the trigger mount is accessed it's not possible for
autofs to know how to translate $USER in these keys when the
trigger mount is mounted.
> i dont want to mount a users home dir with this configuration. i want to
> mount a directory under a users home dir, regardless of anything to do with
> where or how the users home dir is mounted, etc.
Perhaps you should consider using amd.
You would need to build it yourself on the target machine to
enable the regular expression key matching feature as it too
comes with warnings about requiring full map scans on every
But it might do what you require.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.