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 awkward since I have a couple of systems which can be
booted into either 2.0 kernels or 2.1 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 to replace smbmount which would determine
if it was running on a 2.1 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.
To install, 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 .
Weird caveats... At the bottom of the script, I exec the samba
version of the smbmount program. For some bizzare reason, if I do not
redirect stdout and stderr to files, smbmount hangs when exec'ed from
autofs but works fine when run by hand. The difference? When exec'ed
from autofs, stdout and stderr are going to syslog. The samba smbmount/smbmnt
combination doesn't seem to like that. They work fine if going to a terminal
or to a file though. I also get some odd errors in both the .out and .err
files which seem to indicate the command failed, when it did actually
succeed. Well... I needed something to continue to play with now, didn't I.
Getting smbmount and smbmnt to compile under RedHat 5.0 is a real
delight (heavy sarcasm), and I've already send mail up to samba-technical
about that. The smbumount program from the latest cvs sources will not
compile and link without some changes which have nothing to do with the
platform (it's just busted due to some pstring stuff) and has also been
reported, but do we really need smbumount? What is it doing that umount
isn't?
It would be nice if this script or something similar could show up in
the samba package for those who need it. In the mean time, it's short enough
to include below without offending too many "don't post source code" types
(trust me - I'm one of them). You can get the latest copy of this message
the following URL.
http://www.wittsend.com/mhw/smbmount.html
I'll try and keep this up to date and add some more information as
time goes on if need be. Of course, the script is also available from
there as well.
Regards,
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!============================================================================= #!/bin/sh -
# smbmount.sh - a front end shell script to discriminate between new style # smbmount requests as recognized by the smbmount that comes with # samba for the 2.1 kernels and the old style smbmount requests # as generated by autofs and recognized by the 2.0 kernel and smbfs # package. If we have the 2.1 kernel, we have to perform some # rather ugly parameter translations. Some of the parameters # don't map, but most of them aren't used by autofs anyways!
# I needed something like this because I have systems which use # autofs and which can switch between 2.0 kernels and 2.1 kernels.
# Michael H. Warfield, mhw@wittsend.com 6/9/1998
# Free to use - enjoy - just don't blame me... :-)
# # Installation proceedure: # # Install smbmount from smbfs as /usr/sbin/smbmount.smbfs # Install smbmount from samba as /usr/sbin/smbmount.samba # Install this script as /usr/sbin/smbmount # # Make sure you delete any copies of smbmount from /usr/bin !
# Which version case `uname -r` in 1.*) # Give me a break... echo "No way this version" exit 255 ;;
2.0) # 2.0 uses the paramters as passed to us. Just exec the real McCoy. exec /usr/sbin/smbmount.smbfs $* ;; 2.*) # This be good... Let him pass and be processed for # smbclient style arguements... ;; *) # Huh? echo "Unrecognized kernel version" exit 255 ;; esac
SERVICE=$1 shift MOUNTPOINT=$1 shift
# This could be cleaner. Like we could use getopts and all like that. # Autofs doesn't require it, but it might be kinda nice.
while test "$1" != "" ; do case $1 in -P) shift PASSWORD="$1" NOPASS="-N" ;; -U) shift OPTIONS="$OPTIONS -U $1" ;; -n) NOPASS="-N" ;; -c) shift OPTIONS="$OPTIONS -n $1" ;; -D) shift OPTIONS="$OPTIONS -W $1" ;; -u) shift SMBUID="-u $1"; ;; -g) shift SMBGID="-g $1"; ;; -m) # -m max_xmit max_xmit offered (used only for testing) # Pitch the parameter with it shift ;; -d) # -d mode permission the dirs get (octal notation) # Pitch the parameter with it shift ;; -f) # -f mode permission the files get (octal notation) # Pitch the parameter with it shift ;; -C) # Don't convert password to uppercase # What are we suppost to do with this??? ;; *) # Copy everything else over and hope nothing breaks... OPTIONS="$OPTIONS $1" ;; esac shift done
# The redirects at the end of the exec are required to avoid some weird hang # condition that I suspect has something to do with the samba smbmount # program wanting stderr for something and it not being there when # forked from autofs... Still poking at that one...
exec /usr/sbin/smbmount.samba $SERVICE "$PASSWORD" $NOPASS $OPTIONS -c "mount $MOUNTPOINT $SMBUID $SMBGID" < /dev/null > /tmp/smbmount.out 2> /tmp/smbmount.err
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu