Trying to setup autofs

So I am trying to set up autofs (Autofs - ArchWiki) on fedora so I can automatically mount smb shares upon access (I don’t want to use fstab as wifi is not available on boot up is it will just cause my boot up to be delayed.)

So far I have been able to get it to automaticly find all smb shares on my network so i can cd into them but upon doing so I get an error that the share’s folders do not exist

ls: cannot access 'skynet': No such file or directory
ls: cannot access 'shield': No such file or directory
ls: cannot access 'samba': No such file or directory
ls: cannot access 'nsru': No such file or directory
ls: cannot access 'entware': No such file or directory
ls: cannot access 'Share': No such file or directory
ls: cannot access 'Rclone': No such file or directory
entware  nsru  Rclone  samba  Share  shield  skynet

and this is where I am stuck. I have already passed a cred file for this sever so I don’t think its a username/password issue. here is how my auto.master:

 ✘ zany130@localhost  /cifs/192.168.2.1  cat /etc/auto.master 
#
# Sample auto.master file
# This is a 'master' automounter map and it has the following format:
# mount-point [map-type[,format]:]map [options]
# For details of the format look at auto.master(5).
#
/misc	/etc/auto.misc
#
# NOTE: mounts done from a hosts map will be mounted with the
#	"nosuid" and "nodev" options unless the "suid" and "dev"
#	options are explicitly given.
#
/net	-hosts
#
# Include /etc/auto.master.d/*.autofs
# To add an extra map using this mechanism you will need to add
# two configuration items - one /etc/auto.master.d/extra.autofs file
# (using the same line format as the auto.master file)
# and a separate mount map (e.g. /etc/auto.extra or an auto.extra NIS map)
# that is referred to by the extra.autofs file.
#
+dir:/etc/auto.master.d
#
# If you have fedfs set up and the related binaries, either
# built as part of autofs or installed from another package,
# uncomment this line to use the fedfs program map to access
# your fedfs mounts.
#/nfs4  /usr/sbin/fedfs-map-nfs4 nobind
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#

/cifs  /etc/auto.smb --timeout=300

+auto.master

and how my auto.smb looks like:

zany130@localhost  /cifs/192.168.2.1  cat /etc/auto.smb   
#!/usr/bin/bash

# This file must be executable to work! chmod 755!

# Automagically mount CIFS shares in the network, similar to
# what autofs -hosts does for NFS.

# Put a line like the following in /etc/auto.master:
# /cifs  /etc/auto.smb --timeout=300
# You'll be able to access Windows and Samba shares in your network
# under /cifs/host.domain/share

# "smbclient -L" is used to obtain a list of shares from the given host.
# In some environments, this requires valid credentials.

# This script knows 2 methods to obtain credentials:
# 1) if a credentials file (see mount.cifs(8)) is present
#    under /etc/creds/$key, use it.
# 2) Otherwise, try to find a usable kerberos credentials cache
#    for the uid of the user that was first to trigger the mount
#    and use that.
# If both methods fail, the script will try to obtain the list
# of shares anonymously.

get_krb5_cache() {
    cache=
    uid=${UID}
    for x in $(ls -d /run/user/$uid/krb5cc_* 2>/dev/null); do
        if [ -d "$x" ] && klist -s DIR:"$x"; then
	   cache=DIR:$x
            return
        fi
    done
    if [ -f /tmp/krb5cc_$uid ] && klist -s /tmp/krb5cc_$uid; then
	   cache=/tmp/krb5cc_$uid
	   return
    fi
}

key="$1"
opts="-fstype=cifs"

for P in /bin /sbin /usr/bin /usr/sbin
do
	if [ -x $P/smbclient ]
	then
		SMBCLIENT=$P/smbclient
		break
	fi
done

[ -x $SMBCLIENT ] || exit 1

creds=/etc/creds/$key
if [ -f "$creds" ]; then
    opts="$opts"',uid=$UID,gid=$GID,credentials='"$creds"
    smbopts="-A $creds"
else
    get_krb5_cache
    if [ -n "$cache" ]; then
        opts="$opts"',multiuser,cruid=$UID,sec=krb5i'
        smbopts="-k"
        export KRB5CCNAME=$cache
    else
        opts="$opts"',guest'
        smbopts="-N"
    fi
fi

$SMBCLIENT $smbopts -gL "$key" 2>/dev/null| awk -v "key=$key" -v "opts=$opts" -F '|' -- '
	BEGIN	{ ORS=""; first=1 }
	/Disk/	{
		 if (first)
			print opts; first=0
		 dir = $2
		 loc = $2
		 # Enclose mount dir and location in quotes
		 print " \\\n\t \"/" dir "\"", "\"://" key "/" loc "\""
		}
	END 	{ if (!first) print "\n"; else exit 1 }
	'

1 Like

I tried to use something similar along with SSHFS.
Unfortunately, it wasn’t enough flexible and reliable.
So, I eventually replaced it with SFTP/SMB over GVFS:

mkdir -p ~/.config/gtk-3.0
tee -a ~/.config/gtk-3.0/bookmarks << "EOF" > /dev/null
sftp://host/path
smb://host/share
EOF

There’s the option “nofail” you can add to the fstab to prevent this waiting.
It’s a good idea to use “_netdev” and “nofail” for filesystems mounted over the network.

https://man7.org/linux/man-pages/man5/fstab.5.html

After your wifi is up, you can mount it with mount -a

.

However, “nofail” may not work with auto mount.

You try to auto mount with kerberos?

1 Like

Since it is a bash script, you might be able to get some helpful clues about where it is failing by temporarily adding set -ex just after the shebang line and running it manually. You should then be able to see line-by-line debugging output as the script runs in your console. According to man autofs.5, the only parameter to the script should be the “key” which is the name of the server that you are attempting to connect to. It looks like it gets the username and password from a file by the same name as the “key” under /etc/creds (i.e. /etc/creds/<host.domain>). See man smbclient for documentation about how the lines of the credentials file should be formatted.

2 Likes

I tried that and couldnt find anything wrong

/etc/auto.smb RT-AX86U-F748 
+ key=RT-AX86U-F748
+ opts=-fstype=cifs
+ for P in /bin /sbin /usr/bin /usr/sbin
+ '[' -x /bin/smbclient ']'
+ SMBCLIENT=/bin/smbclient
+ break
+ '[' -x /bin/smbclient ']'
+ creds=/etc/creds/RT-AX86U-F748
+ '[' -f /etc/creds/RT-AX86U-F748 ']'
+ get_krb5_cache
+ cache=
+ uid=1000
++ ls -d '/run/user/1000/krb5cc_*'
+ '[' -f /tmp/krb5cc_1000 ']'
+ '[' -n '' ']'
+ opts=-fstype=cifs,guest
+ smbopts=-N
+ /bin/smbclient -N -gL RT-AX86U-F748
+ awk -v key=RT-AX86U-F748 -v opts=-fstype=cifs,guest -F '|' -- '
	BEGIN	{ ORS=""; first=1 }
	/Disk/	{
		 if (first)
			print opts; first=0
		 dir = $2
		 loc = $2
		 # Enclose mount dir and location in quotes
		 print " \\\n\t \"/" dir "\"", "\"://" key "/" loc "\""
		}
	END 	{ if (!first) print "\n"; else exit 1 }
	'
-fstype=cifs,guest \
	"/nsru" "://RT-AX86U-F748/nsru" \
	"/entware" "://RT-AX86U-F748/entware" \
	"/skynet" "://RT-AX86U-F748/skynet" \
	"/Rclone" "://RT-AX86U-F748/Rclone" \
	"/samba" "://RT-AX86U-F748/samba" \
	"/Share" "://RT-AX86U-F748/Share" \
	"/shield" "://RT-AX86U-F748/shield"
+ set +ex
 zany130@localhost  /cifs  sudo mv /etc/creds/RT-AX86U-F748.creds /etc/creds/RT-AX86U-F748       
[sudo] password for zany130: 
 zany130@localhost  /cifs  sudo mv /etc/creds/SHIELD.creds /etc/creds/SHIELD        
 zany130@localhost  /cifs  /etc/auto.smb RT-AX86U-F748                                    
+ key=RT-AX86U-F748
+ opts=-fstype=cifs
+ for P in /bin /sbin /usr/bin /usr/sbin
+ '[' -x /bin/smbclient ']'
+ SMBCLIENT=/bin/smbclient
+ break
+ '[' -x /bin/smbclient ']'
+ creds=/etc/creds/RT-AX86U-F748
+ '[' -f /etc/creds/RT-AX86U-F748 ']'
+ opts='-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/RT-AX86U-F748'
+ smbopts='-A /etc/creds/RT-AX86U-F748'
+ /bin/smbclient -A /etc/creds/RT-AX86U-F748 -gL RT-AX86U-F748
+ awk -v key=RT-AX86U-F748 -v 'opts=-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/RT-AX86U-F748' -F '|' -- '
	BEGIN	{ ORS=""; first=1 }
	/Disk/	{
		 if (first)
			print opts; first=0
		 dir = $2
		 loc = $2
		 # Enclose mount dir and location in quotes
		 print " \\\n\t \"/" dir "\"", "\"://" key "/" loc "\""
		}
	END 	{ if (!first) print "\n"; else exit 1 }
	'

the strange thing is I tried mounting the share manually with the same cred file and it worked so idk

Ideally I would want the smb share to be automounted on demand when for example my backup script runs so it can backup to the network drive. altough I guess i could add it to the fstab with nofail, and then add mount -a to my backup script
whats kerberos?

According to those lines, the script is looking for the file /etc/creds/RT-AX86U-F748, not finding it, and falling back to trying to connect with the guest account. That is probably why it is failing.

1 Like

Kerberos is another way of authenticating. It requires a kerberos server to provide the authentication tokens. It is a more complex system that is typically used in enterprise environments to provide single-sign-on (SSO) services. It probably isn’t something that you are interested in.

yeah noticed that it was using guest so I checked my cred file and realized two things

  1. only root was allowed to read to it, so I gave my user read perms( don’t think this should be a prob when ran normally as I think it normally will run as root)
  2. the cred file was named RT-AX86U-F748.cred and it looking for RT-AX86U-F748 so I fixed that
    and i get this
 ✘ zany130@localhost  ~  /etc/auto.smb RT-AX86U-F748 
+ key=RT-AX86U-F748
+ opts=-fstype=cifs
+ for P in /bin /sbin /usr/bin /usr/sbin
+ '[' -x /bin/smbclient ']'
+ SMBCLIENT=/bin/smbclient
+ break
+ '[' -x /bin/smbclient ']'
+ creds=/etc/creds/RT-AX86U-F748
+ '[' -f /etc/creds/RT-AX86U-F748 ']'
+ opts='-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/RT-AX86U-F748'
+ smbopts='-A /etc/creds/RT-AX86U-F748'
+ /bin/smbclient -A /etc/creds/RT-AX86U-F748 -gL RT-AX86U-F748
+ awk -v key=RT-AX86U-F748 -v 'opts=-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/RT-AX86U-F748' -F '|' -- '
	BEGIN	{ ORS=""; first=1 }
	/Disk/	{
		 if (first)
			print opts; first=0
		 dir = $2
		 loc = $2
		 # Enclose mount dir and location in quotes
		 print " \\\n\t \"/" dir "\"", "\"://" key "/" loc "\""
		}
	END 	{ if (!first) print "\n"; else exit 1 }
	'
-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/RT-AX86U-F748 \
	"/nsru" "://RT-AX86U-F748/nsru" \
	"/entware" "://RT-AX86U-F748/entware" \
	"/skynet" "://RT-AX86U-F748/skynet" \
	"/Rclone" "://RT-AX86U-F748/Rclone" \
	"/samba" "://RT-AX86U-F748/samba" \
	"/Share" "://RT-AX86U-F748/Share" \
	"/shield" "://RT-AX86U-F748/shield"
+ set +ex

and I still get the same

zany130@localhost  /cifs/RT-AX86U-F748  ls
ls: cannot access 'skynet': No such file or directory
ls: cannot access 'shield': No such file or directory
ls: cannot access 'samba': No such file or directory
ls: cannot access 'nsru': No such file or directory
ls: cannot access 'entware': No such file or directory
ls: cannot access 'Share': No such file or directory
ls: cannot access 'Rclone': No such file or directory
entware  nsru  Rclone  samba  Share  shield  skynet

 ✘ zany130@localhost  /cifs/RT-AX86U-F748  cd samba/
cd: no such file or directory: samba/

tried rebooting my system and also tried allowing guest auth on my smb server and moving the cred folder so it wouldn’t use that and the same result I can’t cd into any folder.

How is that last command –

mount -fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/RT-AX86U-F748 "://RT-AX86U-F748/skynet" "/cifs/RT-AX86U-F748/skynet"

– different from the successful mount command that you can run manually?

I found a (very) old bug report that hints that it may work if the colon character is removed: 127009 – autofs incorrectly parses smbfs (and cifs) mount points on the mount map

I guess as a last resort, you could try that workaround?

P.S. Found lots of cool tips here: TipsAndTricks/WindowsShares - CentOS Wiki

1 Like

well this works

mount -t cifs //RT-AX86U-F748/skynet /smb/ -o username=zany130

but this which is the format the script is using doesn’t

mount -fstype=cifs,username=zany130 //RT-AX86U-F748/skynet /smb/skynet

My bad. The mount command doesn’t take the options in exactly the same format as automount. -fstype=cifs,username=zany130 should translate to -t cifs -o username=zany130 when passed to mount.

Also, automount will automatically create the subdirectory whereas mount will not.

Also, be sure the autofs service is stopped if you are trying to test the mount command against the same path that you have configured in autofs. You can see if autofs is holding a lock on the mountpoint by running:

findmnt -t autofs

Other than that, it is not obvious to me what the problem could be. IMO, I’d probably give up on auto.smb and use the “Yet Another Even-better method” for automounting cifs shares.

Just my two cents.

2 Likes

Your script is including a function called “get_krb5_cache”.
This seems to be aimed at Kerberos.
However, if you don’t use it, it should not be a problem.

Does it work if you mount the shares on commandline?

Edit
I now saw that you successfully mounted it by

mount -t cifs //RT-AX86U-F748/skynet /smb/ -o username=zany130

that was the script that was included with the autofs package. and yes I am able to mount the share manually and access the files without issue

@zany130
Interesting.
Did you notice the difference with the mount point?
/smb/ vs. /smb/skynet
Well, maybe this is not so important, however better double check permissions.

Does the command that doesn’t work have an error message?

If you start the auto mount what does
dmesg --level warn,crit,err
say?

there are no errors just nothing happens dmesg shows nothing either.

though I found some interesting points.

  1. my nvidia shield’s smb share is now working ( I could of sworn it wasn’t before) but only if I use the ip address (I think this is because my system is not resolving hostnames correctly just tried mount -t cifs //SHIELD/internal /smb/shield -o username=zany130 and mount -t cifs //RT-AX86U-F748/skynet /smb/asus -o username=zany130 and they didn’t work unless I used the ip (don’t know how I got it to work before then))

so cd /cifs/192.168.2.198/internal/DCIM works but cd /cifs/SHIELD/internal/DCIM see’s the folders but gives the no such file or directory error that I been getting.

  1. my routers smb still can’t be accessed regardless if I use the ip or the hostname (RT-AX86U-F748)
    as again I can see the folders but trying to cd into them gives a no such file or directory error.

I thought maybe running the script with debugging with the two different ip address might reveal something but idk the only difference is when run with the routers ip it lists folders at the end and when ran with the shield ip it doesn’t so nothing useful. if you where to look at the two outputs you would think everything is working fine, in fact you might think the output with the shield ip was not working since it didn’t list directories.

NOT WORKING

/etc/auto.smb 192.168.2.1
+ key=192.168.2.1
+ opts=-fstype=cifs
+ for P in /bin /sbin /usr/bin /usr/sbin
+ '[' -x /bin/smbclient ']'
+ SMBCLIENT=/bin/smbclient
+ break
+ '[' -x /bin/smbclient ']'
+ creds=/etc/creds/192.168.2.1
+ '[' -f /etc/creds/192.168.2.1 ']'
+ opts='-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/192.168.2.1'
+ smbopts='-A /etc/creds/192.168.2.1'
+ /bin/smbclient -A /etc/creds/192.168.2.1 -gL 192.168.2.1
+ awk -v key=192.168.2.1 -v 'opts=-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/192.168.2.1' -F '|' -- '
	BEGIN	{ ORS=""; first=1 }
	/Disk/	{
		 if (first)
			print opts; first=0
		 dir = $2
		 loc = $2
		 # Enclose mount dir and location in quotes
		 print " \\\n\t \"/" dir "\"", "\"://" key "/" loc "\""
		}
	END 	{ if (!first) print "\n"; else exit 1 }
	'
-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/192.168.2.1 \
	"/nsru" "://192.168.2.1/nsru" \
	"/entware" "://192.168.2.1/entware" \
	"/skynet" "://192.168.2.1/skynet" \
	"/Rclone" "://192.168.2.1/Rclone" \
	"/samba" "://192.168.2.1/samba" \
	"/Share" "://192.168.2.1/Share" \
	"/shield" "://192.168.2.1/shield"
+ set +ex
 


WORKING

zany130@localhost  /cifs/SHIELD  /etc/auto.smb 192.168.2.198
+ key=192.168.2.198
+ opts=-fstype=cifs
+ for P in /bin /sbin /usr/bin /usr/sbin
+ '[' -x /bin/smbclient ']'
+ SMBCLIENT=/bin/smbclient
+ break
+ '[' -x /bin/smbclient ']'
+ creds=/etc/creds/192.168.2.198
+ '[' -f /etc/creds/192.168.2.198 ']'
+ opts='-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/192.168.2.198'
+ smbopts='-A /etc/creds/192.168.2.198'
+ /bin/smbclient -A /etc/creds/192.168.2.198 -gL 192.168.2.198
+ awk -v key=192.168.2.198 -v 'opts=-fstype=cifs,uid=$UID,gid=$GID,credentials=/etc/creds/192.168.2.198' -F '|' -- '
	BEGIN	{ ORS=""; first=1 }
	/Disk/	{
		 if (first)
			print opts; first=0
		 dir = $2
		 loc = $2
		 # Enclose mount dir and location in quotes
		 print " \\\n\t \"/" dir "\"", "\"://" key "/" loc "\""
		}
	END 	{ if (!first) print "\n"; else exit 1 }
	'

As a work around that may be suitable if you only have a small number of client systems, you can add names to be resolved to your client system’s /etc/hosts file like so:

192.168.2.1 rt-ax86u-f748
192.168.2.198 shield

The multiple folders are what is called a “multi-map”. It is a fancy feature of automount that is supposed to allow the mounting of several shares all at once. From the documentation:

Multiple Mounts

A multi-mount map can be used to name multiple filesystems to mount. It takes the form:

key [ -options ] [[/] location [/relative-mount-point [ -options ] location…]…

This may extend over multiple lines, quoting the line-breaks with `\´. If present, the per-mountpoint mount-options are appended to the default mount-options. This behaviour may be overridden by the append_options configuration setting.

The man page (autofs.5) also provides an example:

server -rw,hard / -ro myserver.me.org:/ \
                /usr myserver.me.org:/usr \
                /home myserver.me.org:/home

The way the multi-maps are shown in the documentation, however, it appears that the additional mounts are expected to be nested beneath a single top-level mount. CIFS does not work that way though. You cannot mount the level above the shares. Each share is its own root and must be mounted individually. It doesn’t look like multi-maps where ever really designed to work with CIFS. It is possible that the multi-map specification has changed and autofs.smb was never updated to comply with the new syntax (maybe it cannot be). I wonder if anyone has gotten this to work in recent history?

I think an equivalent “autofs.cifs” could/should be created based on what was provided in that earlier link that would not attempt to use multi-maps but instead would mount each share individually on demand. The latter seems a much better approach as it would be unlikely that one broken share (e.g. the account doesn’t have access) could prevent the rest of the shares from working. I’ll try to provide a compatible “autofs.cifs” based on the documentation in a bit. Unfortunately, I don’t have a good system to test anything on.

Based on TipsAndTricks/WindowsShares - CentOS Wiki, I think the following should work as a drop-in replacement for /etc/auto.smb.

  1. stop the autofs service
    # systemctl stop autofs.service

  2. remove the “/cifs …” line from /etc/auto.master if it exists
    # sed -i '\%^/cifs\b% d' /etc/auto.master

  3. create /cifs if it does not already exist
    # mkdir -p /cifs

  4. remove any leftover mountpoints if they exist
    # find /cifs -mindepth 1 -depth -type d -exec rmdir {} \;

  5. define the new configuration files

    # echo "/cifs /etc/auto.cifs-servers" > /etc/auto.master.d/cifs.autofs
    # echo "* -fstype=autofs,-Dhost=& file:/etc/auto.cifs-shares" > /etc/auto.cifs-servers
    # echo "* -fstype=cifs,credentials=/etc/creds/${host},uid=${UID},gid=${GID} ://${host}/&" > /etc/auto.cifs-shares
    
  6. start the autofs service
    # systemctl start autofs.service

The configuration files provided above have been designed to use the same credentials files, from the same file system location, as the auto.smb script. This may be particularly important if SELinux is enabled as there may be special rules about what files the autofs service can access.

Let me know if the above configuration files work and I might try to get them submitted to the autofs project for standard inclusion in Fedora Linux.