More Questions On Setting Up Autofs On C7

Home » CentOS » More Questions On Setting Up Autofs On C7
CentOS 10 Comments


Thanks to some of you I got autofs set up on my C7 netbook for mounting local cifs filesytems.

Now I want to do something on my C7 desktop machine, that seems to me to be a little different, and I”m not sure how to do it.

I have an external RAID1 box that attaches via USB. It is/will be nearly always /dev/sdc, but being USB I can’t guarantee that it will always be found there.

accordingly, in my /etc/fstab I have an entry that mounts it via its UUID:

UUID bfc97a-8db2-46de-b4dd-427da19b114 /mnt/backup xfs defaults,noauto,users 0 2

and I’m wondering how to specify that in an autofs recipe instead…

If doing cifs mounts, /etc/auto.master may contain this line:

/mymount /etc/auto.mymount

then there would be a file /etc/auto.mymount that contains a line similar to this:

winbox -fstype=cifs,rw,noperm,user=sushi,pass=yummy ://winbox/getme

so, in my case, the USB drive contains an xfs filesystem. would I
do something like this:

in /etc/auto.master:

backup /etc/auto.backup

and in /etc/auto.backup

backup -fstype=xfs,defaults,noauto,users :UUID bfc97a-8db2-46de-b4dd-427da19b114

Would that be expected to work, or am I all overlooking something obvious?

Thanks in advance for your advice!


10 thoughts on - More Questions On Setting Up Autofs On C7

  • In auto.master, the first field is a directory, so it should be “/backup”.

    Debian’s documentation says you shouldn’t need to prefix UUID with a
    ‘:’, so remove that from auto.backup if the configuration you described doesn’t work. Alternatively, you could specify its location as

  • Ok, when I actually tried it, I did it this way:

    /etc/auto.master (excerpt):

    /mnt /etc/auto.mnt

    and /etc/auto.mnt:

    backup -fstype=xfs,defaults,noauto,users,rw :UUID bfc97a-8db2-46de-b4dd-427da19b1143

    and lo and behold, it works!


    I have a couple of other networked filesystems (cifs) that I have always mounted in /mnt. so, after accessing either of them, systemctl status autofs shows me this:

    Aug 23 15:46:02 systemd[1]: Starting Automounts filesystems on demand… Aug 23 15:46:02 automount[11265]: setautomntent: lookup(sss): setautomntent: No such fil…ory Aug 23 15:46:02 systemd[1]: Started Automounts filesystems on demand. Aug 23 15:50:04 automount[11265]: key “syno-fredex” not found in map source(s). Aug 23 15:50:04 automount[11265]: key “syno-public” not found in map source(s).

    the first error regarding setautomntent seems to be pretty universal, as I see lots of questions about it (and bugs filed against Fedora and RHEL) but no actual solution. the consensus is that it doesn’t seem to prevent autofs from working. (there is a workaround that I haven’t tried, and mention of a patch to sssd that I also haven’t tried, and which apparently hasn’t made it into RHEL 7.3 or CentOS7.x).

    so, the two lines saying: Key “syno-fredex” or key “syno-public”
    appear whenever I try to access one of those two filesystems. I AM NOT
    USING AUTOFS TO MANAGE THEM. they were mounting in /mnt, just like the automount I was asking about. thinking since autofs was looking in /mnt for the backup mount that it was getting all confuzzled, I changed the mount point of those other two filesystems, changed their entries in
    /etc/fstab, reran systemctl restart autofs then touched one of those cifs filesystems. Voila! the errors still appear in the output of systemctl status autofs.

    Everything still appears to work, but I’m puzzled by those two errors.

    Anyone got any good ideas on this?

    thanks in advance!


  • You’re using autofs to manage /mnt, so any time that *any* process attempts to access /mnt/syno-fredex or /mnt/syno-public, you’ll get those errors. That’s how autofs works: access attempts in an autofs managed directory get passed to autofs, which looks at its maps to determine how to mount the path being accessed. The error you see is autofs telling you that something is trying to access “syno-fredex”
    under /mnt, but it doesn’t have a map indicating how to mount a filesystem in a directory of that name.

  • yeah, that’s what I figured.

    so I created /mounts and moved those two mounts to that directory. the restarted autofs, but the errors still come when accessing those two mounts.

    do I need to reboot or something to get autofs to forget about them being in /mnt?

    Thanks again!

  • No, you need to figure out what program, not autofs, is trying to access
    /mnt/syno-fredex and /mnt/syno-public.

    You moved the mounts, but some program still expects those paths to exist. autofs is just telling you that some other program is still looking in that location.

  • Gordon, thanks for the followup.

    I have a desktop icon for opening a window in each of those two mounts
    (the mounts occur at system boot), the icons are backed up by .desktop files:

    cat NAS-fredex.desktop
    #!/usr/bin/env xdg-open

    [Desktop Entry]
    Type=Link Icon[en_US]=system-logo-icon Name[en_US]=NAS-fredex URL=/mounts/syno-fredex Name=NAS-fredex Icon=/usr/share/icons/mate/48×48/places/network_local.png

    cat NAS-public.desktop
    #!/usr/bin/env xdg-open

    [Desktop Entry]
    Type=Link Icon[en_US]=system-logo-icon Name[en_US]=NAS-public URL=/mounts/syno-public Name=NAS-public Icon=/usr/share/icons/mate/48×48/places/network_local.png

    if I click one of those then run systemctl status autofs I see one of those errors show up. If I click on it again, there are two errors. if I click on the other one, a third error shows up.

    nothing else I’ve tried seems to cause them to show up.

    as you can see, neither of them refers to the old mount point on /mnt.

    I know you can’t look thru my computer and see what’s wrong, but I’m puzzl-ified, since /mnt/syno-public isn’t mentioned anywhere in the
    .desktop files. If you can think of anything else that might be happening, I’d appreciate your wisdom.

    thanks once again!


  • Does your file manager have some other link to the old locations? A
    “favorites” entry? Something in the sidebar? More than likely, your file manager is trying to check the old location, not for its primary view which is /mounts/something, but for some other reason.

  • don’t think so. I’m running the Mate desktop. Original install was Gnome (which is I assume what you are thinking of) but I never use it, can’t stand Gnome-3.x.

    Don’t know of anything in mate that would do th at, but I’ll do some digging around.

    thanks once again!

  • You can always look the hard/slow way:

    find ~ -type f -exec fgrep /mnt/syno {} +

    That command should locate any files that refer to the old mount locations.

  • a bunch of things that look merely like log files.

    so, in the meantime I did the update for all the files sitting in the CR repo. rebooted. now the problem is gone. Go figure.