Yet another post from my old website brought back to life — just as with the previous such posts, I hope this still stands. Nowadays I’ve moved most of my “infrastructure” to Amazon, I don’t have to use this anymore, but I remember at the time having to do a bit of research into this to get this automount procedure going. So hopefully is not that out of date and/or misleading!
If you’re using automounter (
autofs) on Debian Linux and you have tried to configure it so it automatically mounts Windows shares automatically via
auto.smb, you probably got stuck like myself at the first step. As you might have noticed, the
auto.smb file actually is a shell script (the
#!/bin/sh shebang in the beginning gives it away and the file permissions) which doesn’t seem to do any mounting! It seems to work though (in certain configurations) if you do a
ls /mountpoint/SAMBA_NAME and it lists all the shares on the machine
SAMBA_NAME. But from there on you should still use
smbmount to mount the share manually.
What I had to do to make it work in the end was to scrap the original file (
/etc/auto.smb) and create my own. So first things first: change the
/etc/auto.master file to include a reference to the
/etc/auto.smb — typically this means just un-commenting a line, but for those who use a slightly different distribution, simply add a line in
/etc/auto.master that looks like that:
/mnt/smb /etc/auto.smb --timeout=60
This will instruct the automounter to look in the
/etc/auto.smb file for any file requests under
/mnt/smb directory. (Needless to point out maybe, but worth it for those not that acquainted to the mounting procedure, that the directory
/mnt/smb must exist. Also, it doesn’t have to be this specific directory, this path is only given as an example.)
Secondly, make sure that the
/etc/auto.smb is not an executable file — simply issue:
chmod a-x /etc/auto.smb
The reason for that is because the automounter looks at the file attributes first and if it finds the execution flag enabled, it will treat it as a script and try to execute it (so it will start a shell and try to run this file inside it — obviously the file could then “request” a
perl interpreter etc); if however, the file attributes do not include the execution flag, then the automounter will decide this is actually a simple configuration file and parse it per normal and read the mount points and the corresponding mount options.
Make sure that you clear the exec flag before you decide to restart the automounter later on — failing to do that will mean that even though you have configured the file correctly, as shown below, the automounter will still think the file is a shell script and try to run it in a shell rather than parse it as a normal configuration file!
Having made sure the
/etc/auto.smb is just a regular file, you can add the mount points same as you probably have done with all the other
pc1_c -fstype=smbfs ://pc1/C$ pc2_private -fstype=smbfs,username=privateuser,password=youwish ://pc2/privateshare
The above example declares 2 mount points to be mounted under
pc1_c— this maps the standard system share (
pc1_cwithout any authentication required. In this case, chances are that the share is a public (read-write access for everyone) and no username/password is needed to map/mount it.
pc2_private— this maps a “private” share (i.e. a share which requires a certain user name and password in order to access it) under
pc2_private, obviously if the username/password combination is valid. Be aware that by doing this you grant access to any user to use that share on the pc2 machine without the need to know the username and password combination to access it, as the automounter would automatically mount it for them as that specific user!
After you’re done changing
auto.master) restart the
autofs service (
/etc/init.d/autofs restart) and do a simple
ls /mnt/smb/pc1_c — which should list the contents of the
C: drive on machine PC1. Same for
ls /mnt/smb/pc2_private which should list the contents of the share
privateshare on machine PC2. Because you have specified a timeout value of 60 seconds (
auto.master), these 2 mount points would be automatically unmounted after 1 minute of inactivity — so you’re freeing up resources automatically.
Last but not least, it is worth mentioning that if you do include username and passwords in the
/etc/auto.smb file, make sure that you are indeed happy with an ordinary user (who might not have access to the shared folder on the Windows machine normally) being able to browse (or even more to write/delete/modify) files on that folder. And even if you are happy with that, you still might not be happy with your users actually getting access to the username/password combination needed to access that share! So it’s a good (read recommended!) idea to secure the file
/etc/auto.smb if you’re including usernames and passwords in it:
chmod 600 /etc/auto.smb
This will make sure that only the owner of the file (typically root — if it isn’t make sure you
chown it to
root) will have just read and write access. (Again, see the notes above, do not enable execution rights as this will trigger the automounter to try to execute the
/etc/auto.smb file rather than use it simply as a configuration file!) This way, your file (and its contents) is as secure as access to your root account is.
More from my site