smbmount and Linux 2.2.x

[Paul]

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.
 
> 	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!
>