smbmount and Linux 2.2.x

Michael H. Warfield mhw at wittsend.com
Sun Jan 31 21:43:22 GMT 1999 

	OK!  Fixes are IN the CVS tree!

James Willard enscribed thusly:
> In my original post, I probably should have mentioned that I use neither
> glibc or autofs. Both systems are simply libc5 (5.4.46) and manually mounted
> by issuing the smbmount command.

	Yeah...  No problem.  The original autofs timing problem broke the
PID registration.  I had the fix for that and was just holding of on commiting
that fix, because it uncovered this NASTY deadly embrace problem.  H Peter
Anvin just got back to me with the clue to fixing that one.  I also added
code to smbumount.c to deal with the uid_t changes that ARE glibc related.

	Anyone who was changing the uid_t to uint16 should back that out!
That is incorrect, although it works right now with the current kernels.
The correct change was to change it to __kernel_uid_t so that it can track
changes to the kernel uid_t definition.

	All of the changes to fix the race condition, the deadly embrace,
the PID registration problem and the smbumount problem are now commited
into the Samba CVS tree on the main branch.

	Left to do - deal with the $#$#@ syntax so that autofs does not
need a frontend script to deal with smbmount...  Sigh...

> James D. Willard
> james at cows.ml.org
> 
> > 
> > On Sun, 31 Jan 1999, Michael H. Warfield wrote:
> > 
> > > Paul enscribed thusly:
> > > 
> > > > My guess is that this is related to my earlier post about smbmount
> > > > mounting before daemonizing. The kernel gets the PID of the parent process
> > > > and not the daemon, so if it needs the connection reset or something it
> > > > sends the signal to the wrong PID. The biggest sign of this is smbmount
> > > > daemons sticking around after the share has been unmounted. Also you
> > > > should see in your syslog:
> > > 
> > > 	Actually, it's a lot more complicate than that.  It was pointed
> > > out to me by someone on one of the Linux lists that the user space uid_t
> > > changed from 16 bits to 32 bits when going from libc to glibc.  This alters
> > > one of the ioctl calls which uses a uid_t parameter.  In user land, this is
> > > a 32 bit quantity.  In kernel land, this is a 16 bit quantity.  That has this
> > > particular ioctl screwed over and it causing some of the information to
> > > be miss-interpreted.
> > 
> > It very well could have been me that pointed this out to you. I am aware
> > of the problem, and the UID problem is unrelated to this issue. Simply
> > redefine the macro in Samba to use a 16 bit uid. It's easy. Everyone is
> > doing it ;). This problem of the kernel getting the wrong pid occurs even
> > on my libc5 box, which has uid_t as 16 bits.

	It should be redefined to use the kernel definition of the uid,
whatever it is (eventually it will be 32 bits).  That definition is
__kernel_uid_t and I'll try and get that into the smb_fs.h file as soon
as I can.

> > > 	I have a fix for the afore mentioned wrong PID problem.  It hasn't
> > > been commited in because I'm chasing a deadly embrace problem between smbfs,
> > > autofs, and smbmount.  In any case, the fix does fix the pid problem but
> > > does not fix this problem.

> > > 	This is also why smbunmount generates an error about "not and SMB
> > > file system".  I'm going to have to get with the smbfs maintainer and work
> > > out some common solution for this, since it boils down to a problem in
> > > smbfs.h.

> > > > smb_retry: signal failed, error=XXX

> > > > Paul Laufer
> > > 
> > > > On Sun, 31 Jan 1999, James Willard wrote:
> > > 
> > > > > 
> > > > >    I've been using Samba on my Linux 2.0.x system for quite a while, and I
> > > > > have been using the smbmount package for Linux. Well, when I moved to Linux
> > > > > 2.2.x recently, I obviously had to use the smbmount that comes with Samba
> > > > > 2.0. Previously, I mounted a SMB share using:
> > > > > 
> > > > > smbmount //jersey/c /jersey/c -U root -g adm -d 770 -f 660 -P ""
> > > > > 
> > > > > Now, using the smbmount and smbmnt utilities that come in the samba 2.0
> > > > > distribution, I type:
> > > > > 
> > > > > smbmount //jersey/c -U root -c "mount /jersey/c -g adm -d 770 -f 660"
> > > > > 
> > > > > Which does successfully mount the share with the mount point being
> > > > > /jersey/c. I am able to access the files as I did with the older smbmount
> > > > > program, but after a period of time, varying between 15 minutes to an hour
> > > > > or more, the connection goes bad. Running ps aux shows the smbmount process
> > > > > still running, but any attempt to access the mounted share gives:
> > > > > 
> > > > > holstein:~$ ls /jersey/c
> > > > > /bin/ls: /jersey/c: I/O error
> > > > > 
> > > > > I am also seeing this same problem on a totally different system. There
> > > > > aren't any problems with other machines connecting to the shares on the
> > > > > Linux boxes, it's just shares mounted from Linux. The setup is as follows:
> > > > > 
> > > > > System 1:     Linux 2.2.1       System 2:     Linux 2.2.0 
> > > > >               Redhat 4.2                      Slackware 3.4
> > > > >               Samba 2.0.0                     Samba 2.1.0-prealpha
> > > > > 
> > > > > My question is: Is anyone else seeing these problems? Is this a Linux
> > > > > problem, Samba problem, or am I basically mounting it wrong in the first
> > > > > place?
> > > > > 
> > > > > Thanks for your time,
> > > > > 
> > > > > James D. Willard
> > > > > james at cows.ml.org
> > > > > 
> > > > > -- 
> > > > > 
> > > > 
> > > 
> > > 
> > > -- 
> > >  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!

> -- 
> James D. Willard  | Linux/FreeBSD/OpenBSD/Novell/Win/DOS/Minix User
> james at cows.ml.org | finger james at cows.ml.org for PGP Public Key
>   #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
>   $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
>   lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> ,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,

	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