smbmount and smbfs (was Re: smbmount et al...)
Michael H. Warfield
mhw at wittsend.com
Mon Sep 28 14:57:51 GMT 1998
Hello!
My original reply to this message appears to have been eaten by
a wayward IPv6 enabled version of sendmail I was putzing with at the time...
Since my status with the Samba team is changing and it looks like I'm going
to end up more involved with this... Here we go again...
I have mention of what appears to be an smbfs kernel module problem
later on in this message, so I'm also including the kernel developer list
in this. Volker may fix the kernel module himself, or he may point me toward
it, or someone else may take on the task...
Volker.Lendecke at SerNet.DE enscribed thusly:
> Hello!
> > I'm also one of the primary bitchers about the change in syntax
> > from the old smbfs version of smbmount to the new samba version of smbmount.
> > I'm not going to go down the road of why it got where it is or why it should
> > or shouldn't have. We have users that are heavily invested in it and we
> > have some responsibility to the sins of the past... So be it.
> Is it only the syntax that annoys you or is it also the kernel-level
> interface? I must admit that the syntax is really ugly, but it was the
> fastest way to get something use the kernel interface. IMO this kernel
> interface is necessary, as I did not want all the fancy stuff like
> netbios name lookup or encrypted passwords in the kernel. The syntax
> could be improved, making the 2.1 stuff look very similar to the 2.0
> smbmount and still use smbclient to do the authentication.
It's primarily the syntax change. The syntax change broke the
bejesus out of autofs, and any other scripts that thought they understood
smbmount, and to call the fix "less than pretty" would be paying it high
praise. One optional parameter became positional while several optional
parameters got combined with one positional parameter and subsumed into a
mount command string single parameter!
This is compounded by the problems introduced by many of us who
switch back and forth between 2.0 and 2.1 kernels for testing. Due to
the change in the kernel interface, we are stuck with two binaries anyways.
But we also end up with two incompatible command syntaxes to deal with as
well. So, now, what should have been understood and buried in one command
(even if it resolves to two binaries) requires anyone and anything which
calls it to also understand and switch syntax based on the conditions that
would switch the binaries. It would have been nice to support backward
compatibility in the new program against the old interface, but that's
a minor point compared to the frontend problems. I understand the need
for the kernel interface change, agree with it, and can live with that.
It gets really entertaining to look at some of the headstands that
some people are doing to get some of this to work! Someone else told
me that they had a "mount.smb" script that they used with mount. If
you call mount with a file system type and it finds a "mount.type"
executable, it execs that executable. His script would then look up user
names and passwords and anything else it needed and call smbmount. Well...
He also needed to workaround the byzantine syntax gyrations depending on
kernel version. So he calls my smbmount script which, in turn, calls
smbmount.samba, which, in turn, calls mount! Here's how that one plays out:
autofs -> mount -t smb -> mount.smb -> smbmount -> mount.samba -> mount
Ultimately, mount ends up calling mount...
That's scary!
Talking with Luke in my office, I understand some of the history and
the why's and wherefore's behind putting smbmount, et al, into samba. I
also understand that Tridge and Jeremy, et al, are rightfully frustrated by
a package that they don't use and currently can't support. Hopefully, I'm
going to aid in easing that problem instead of compounding it by piling
on more complaints.
I looked into fixing autofs to understand the new syntax. I
thought "how hard could it be?" Yeah right. My thought was to first get
autofs to understand the new syntax and then get it to go "bi" and switch
depending on kernel version. The current autofs plugs in the two position
parameters (the resource and the mount point) and then proceeds to process
the remaining parameters into options. As I dug deeper into what was going
to be required to rearrange those parameters, plus synthesize the mount
command string with the mount point PLUS optional parameters, it just kept
getting uglier and uglier. It was going to need a complete rewrite of
a couple of core parsing routines and then I realized that to "switch on
the fly" based on kernel version, I was going to have to have both the
old set of routines and the new set of routines, rather than even attempt
to get a single routine to parse out and synthesize the parameter list.
Then, on top of that, it was going to have to know how to find each of
those two unique binaries... Sigh...
I finally threw up my hands and wrote an smbmount wrapper script
that takes the place of smbmount, and checks the kernel version. It then
calls smbmount.smbfs if the kernel version is 2.0.x, or munges the parameters
into the new syntax and calls smbmount.samba if the kernel version is 2.1.x
(anyone still using 2.1.x prior to 2.1.70 gets no sympathy...) I also
found that I had to do some "magic" with the smbmount.samba output and
input, since the samba smbmount seems to hang if it is piped to syslog. My
hacks for that then seem to have broken interactive use of smbmount (password
prompting got screwed). Just found that one two days ago... (Grumble)
I've got some other patches to the smbmount script that have been
contributed by others that I haven't integrated in as yet.
The script is available at:
http://www.wittsend.com/smbmount.html
With the 2.2 kernels on the horizon, backward compatibility may
become less and less an issue, but it would be nice to have the new smbmount
program recognize older kernel version and fork off the old smbmount as
needed. That would eliminate my script and simplify things immensely
(especially installation and updates in a mix environment). If I can
munge around the parameter parsing to understand the old syntax, that would
solve a lot of problems. The new syntax has been in use long enough, at
this point, that it can't be just abandoned either (or I'm doing exactly
what I'm bitching about to everyone else). Yer damned if you do and
damn'ed if you don't... Input and feedback on what direction to take
here would be vastly appreciated!
Right now I have several things that I'm looking at. I've already
started going through RECENT messages to samba-bugs regarding smbfs and
have responded to one or two. Most have to do with version breaks and
compiling under different distributions. I'm not sure I'm going to wade
in and answer everything going back 6 months or more, but I'm trying to
get to things only a month or two old. I have at least one smbfs kernel
module problem on my list so I'm also forwarding this message to the
linux-kernel development list.
Here is what is currently on my radar scope:
Samba smbmount/smbmnt/smbumount problems:
1) Smbmount (et al) is not currently supported by the samba 2.0
autoconfigure.
Status: Fixed as soon as I can get the changes committed in.
2) Smbmount does not compile under RedHat 5.1 (or, presumably other
glibc2 systems).
Status: Fixed as soon as I can get the changes committed in.
3) Smbmount goes "daemon" premature causing autofs and other scripts
to return before the mount has succeeded.
Symptoms: If you do an "ls" of an automounted directory that is not
currently mounted, the first attempt will sometimes come back with an empty
directory. Subsequent access shows the directory properly mounted and can
be listed. If you "cd" into a root directory of an automounted partition,
the cd will succeed and a simple "ls" will work but an "ls -l" will return
"no such file or directory" for every filename in the directory. Syslog
entries show multiple mount attempts every time autofs attempts to mount
an smbfs mountpoint.
What has happened is that smbmount forks a copy of itself, which
becomes the smbfs mount daemon, before the mount is completed. The exiting
parent causes autofs to continue as if the mount were finished. Subsequent
accesses may result in additional attempts to mount the pending mount.
The subsequent attempts eventually result in a "mount point busy" error.
In the resulting timing windows, some commands may complete, with erronious
results. An "ls" of a directory may terminate, complete, having gotten no
data. If you cd to a directory, you may have cd'ed to the directory before
the share is mounted on top of the directory you just cd'ed into.
This isn't a problem when running smbmount manually, since the
mount completes long before the user can enter in the next command, but
the timing windows when this is being done from other programs is just
horrendous.
Status: Pending. I think this should be relatively easy to shoot.
4) Smbmount hangs when stdout/stdin/stderr is piped to syslog.
I haven't delved into this one very deeply as yet, but it is a royal
pain in the fanny with regard to autofs. My wild ass guess is that it has
something to do with the password prompting routines...
Status: Pending. I have no real clue as yet...
Smbfs kernel module (2.1.122):
1) Date stamps bear little resemblance to reality.
Here is an example...
Three systems:
Chaos - Linux 2.1.122
Amber - Linux 2.0.35
Phil - Windows NT 4.0 SP3
\\phil\public is mounted on /mnt/phil/public on both Chaos and Amber.
On amber "ls -l /mnt/public" date stamps look reasonable:
drwxr-xr-x 1 root root 512 Aug 27 16:14 t_elvis
drwxr-xr-x 1 root root 512 Sep 10 12:06 tellison
drwxr-xr-x 1 root root 512 Sep 15 16:24 telljohann
-rwxr-xr-x 1 root root 83968 Jun 11 13:14 th.doc
drwxr-xr-x 1 root root 512 Mar 11 1998 tmbackup
drwxr-xr-x 1 root root 512 Jul 14 16:55 to_ftp
drwxr-xr-x 1 root root 512 Aug 19 12:06 tpage
drwxr-xr-x 1 root root 512 Aug 7 17:01 tsavino
drwxr-xr-x 1 root root 512 May 18 16:40 unix_for_nt
-rwxr-xr-x 1 root root 36352 May 9 1996 view_iss.xls
drwxr-xr-x 1 root root 512 Jan 27 1998 vulndb
drwxr-xr-x 1 root root 512 May 29 12:17 web_pages_jl
drwxr-xr-x 1 root root 512 Aug 25 18:21 wingate
-rwxr-xr-x 1 root root 709120 Oct 21 1997 winzip95.exe
drwxr-xr-x 1 root root 512 Jul 28 09:55 winzipnt
-rwxr-xr-x 1 root root 637728 Jan 6 1934 wrd6ex32.exe
-rwxr-xr-x 1 root root 439904 Jun 17 22:18 xlock
drwxr-xr-x 1 root root 512 Apr 21 11:32 xtian
Same listing on chaos shows date/time stamps all over the map...
drwxr-xr-x 1 root root 512 Oct 12 1954 t_elvis
drwxr-xr-x 1 root root 512 Apr 30 1920 tellison
drwxr-xr-x 1 root root 512 Aug 21 2026 telljohann
-rwxr-xr-x 1 root root 83968 Nov 8 1971 th.doc
drwxr-xr-x 1 root root 512 Feb 4 1981 tmbackup
drwxr-xr-x 1 root root 512 Nov 5 2016 to_ftp
drwxr-xr-x 1 root root 512 Jan 14 1969 tpage
drwxr-xr-x 1 root root 512 Jun 25 2001 tsavino
drwxr-xr-x 1 root root 512 Nov 7 1944 unix_for_nt
-rwxr-xr-x 1 root root 36352 Oct 10 1929 view_iss.xls
drwxr-xr-x 1 root root 512 Nov 20 2024 vulndb
drwxr-xr-x 1 root root 512 Mar 17 1960 web_pages_jl
drwxr-xr-x 1 root root 512 Mar 17 2015 wingate
-rwxr-xr-x 1 root root 709120 Jun 14 2023 winzip95.exe
drwxr-xr-x 1 root root 512 Oct 31 1960 winzipnt
-rwxr-xr-x 1 root root 637728 Mar 18 1944 wrd6ex32.exe
-rwxr-xr-x 1 root root 439904 Jun 5 1962 xlock
drwxr-xr-x 1 root root 512 Feb 23 2016 xtian
A directory listing from smbclient agrees with the amber (2.0.35)
date stamps and not with the chaos (2.1.122) date stamps.
I guess this is an invitation to "open season" but... Have I missed
anything? Are there other issues that need investigating?
I DON'T want to end up looking like a bull in a china shop, so I will
need feedback from other users of this animal...
I'm currently waiting on Tridge before I can commit the changes I've
already got. ITMT, I'm continuing to look over the smbfs messages up on
the samba-bugs site...
IMHO... We are in a feature freeze in the 2.1 kernels and building
toward a 2.2 release. Stabilizing smbfs and fixing bugs fits right in there.
The smbmount stuff I'm working on is in the Samba 2.0 alpha line. I don't
know if we are going to need to retrofit things back into the "released"
Samba series or not. Smbmount will not compile on RedHat 5.x systems
currently. We may yet have a beta Samba 2.0 out before Linux 2.2 hits
the street anyways. It's not a jab at the kernel guys but a reflection
on the complexity they are dealing with. Linus was talking about a 2.1
freeze last year at the Atlanta Linux Showcase and we've finally just
gotten there. Where some of this fits in has yet to be clarified.
> Volker
Regards,
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw at 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!
More information about the samba-technical
mailing list