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