smbmount.sh
auto-switch smbfs style and samba style smbmount binaries
Ok ok... I know... It's been a long time since I updated this
page. Things have changed.
I'm now a member of the Samba development team and responsible for
the Samba version of smbmount.
I am not responsible (at this time) for the smbfs kernel module
(2.0 or 2.2) or for the smbfs version of smbmount. The smbfs version of
smbmount is totally deprecated at this point and is no longer being
maintained by anyone, so don't even ask!
I've been fiddling with smbfs and smbmount for a while. I've had
them working with autofs under 2.0 just fine. For those familiar with
the syntax change from the smbmount program in the smbfs package to the
smbmount program in the samba package (required for 2.1.70 and above)
you might get an idea of just what a mess that made with autofs. This
is particularly messy since I have a couple of systems which can be
booted into either 2.0 kernels or 2.2 kernels.
The smbmount with samba is particularly problematical since several
parameters to the old smbmount program are now embedded in a string. The
mount point, the user id, and the group id are now part of the mount
command string passed in under the "-c" parameter. That requires building
the mount string after parsing the mount parameters in autofs... The
hack to change autofs to only work with the new syntax is butt ugly enough.
To get it to work with both is a real mess.
I finally wrote a script, smbmount.sh,
to replace smbmount which would determine if it was running on a 2.2 or
2.0 kernel and call the appropriate binary program with appropriately
translated parameters if required. I didn't worry about whether it was
a 2.1 kernel prior to 70 or not. Anyone who cares about that can hack
the script themselves.
Installation
Install the smbmount program from the smbfs package
as /usr/sbin/smbmount.smbfs and the smbmount program from the samba
package as /usr/sbin/smbmount.samba. Then install this script as
/usr/sbin/smbmount.sh and provide a symlink from it to smbmount. You
can make that symlink from /usr/bin or from /usr/sbin and you can install
smbmount.sh in /usr/bin if you so desire. It really does not care where
it resides. The reason for moving smbmount.smbfs and smbmount.samba to
/usr/sbin is that they should no longer be called directly by a user.
Some people have suggested the names "smbmount-2.0" for the earlier
version of smbmount and "smbmount-2.x" for the newer version. If you like
this, the script has a couple of tuning knobs near the beginning. Your
choice if you so desire.
Weird caveats
At the bottom of the script, I exec the samba
version of the smbmount program. If you have SMBFS_DEBUG enabled in smbmount
automount hangs when it execs smbmount but smbmount works fine when run by
hand. The difference? When SMBFS_DEBUG is enabled, stdin, stdout, and stderr
are not closed. The automounter from autofs is waiting for the pipes to
close before releasing the caller. This never happens in debugging because
the daemon is holding them open. There are redirection lines at the bottom
of the script if you have to run smbmount in debugging mode and need to
run it under autfs. Do this with caution and uncomment the specified lines.
Revision History
Version 0.5 added conversions for the file and directory permissions.
Shell variables were added to select the locations and names of the mount
binaries. The file redirection code which was implimented to avoid the
autofs hand condition was commented out, now that the real cause (SMBFS_DEBUG)
has been determined.
Version 0.4 fixed a comment typo that was generating an error
where a hash was missing.
Version 0.3 fixed a typo where "set nocobber" should have been
"set NOCLOBBER". This was a "backup" to the security fixes and should
not have been an issue anyways.
Version 0.2 fixed some silly but serious security ramifications
on systems with users who like to play silly buggers with symlinks in /tmp.
I don't have any such users on my system so I'll use that as my excuse
for making such an incredibly stupid mistake. Since the script ends up
running as root, the possiblity for mayhem is rife and I should be
more careful.
Page prepared by
Michael H. Warfield - E-Mail:
mhw@wittsend.com
Page last updated: April 18, 1999