smbmount and Linux 2.2.x [RESOLVED]
James Willard
james at cows.ml.org
Mon Feb 1 16:51:27 GMT 1999
Alright! The problem has now been resolved and my SMB shares have stayed
mounted. I would like to thank all of those involved in responding so
quickly. You definately wouldn't see this kind of swiftness in closed-source
proprietary software.
Thanks,
James
>
> 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!
>
--
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*',/((..)*)$/)
.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,.,-=-,
More information about the samba-technical
mailing list