smbmount and Linux 2.2.x

[Michael H. Warfield]

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.

	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!