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 auto.*
files:
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 /mnt/smb
:
pc1_c
— this maps the standard system share (C$
) underpc1_c
without 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) underpc2_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.smb
(and 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 (--timeout=60
in 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.
what you wrote here is totally useless; you should remove so real solutions get a chance being found.
You are probably right — it probably doesn’t work that “out-of-the-box” with newer Debian distros, hence the explanation initially that this might not be entirely accurate.
Out of curiousity, how different is the procedure for this in Debian nowadays?