I am running the latest release of Samba.... consisting of the following rpm's -samba-2.0.7-4.i386.rpm -samba-client-2.0.7-4.i386.rpm -samba-common-2.0.7-4.i386.rpm Has anyone experienced Samba dropping mounts? (NT shares). I am only concerned with accessing my NT Shares, (not the other way around)... and Samba keeps dropping the mounts/shares. I can mount the shares...and access the shares....over and over without any problem....but after a completely random amount of time Samba decides to drop some or all of the mounts and I get "broken pipe" messages when attempting to access them. I unmount all the shares (because not all of the mounts drop at the same time) and I remount them and everything works again. But after an undetermined amount of time Samba just drops them again and I have to remount them again. Does anyone know of a fix to this problem (with the latest version)?
On Mon, 18 Sep 2000 auto852@hushmail.com wrote:> Has anyone experienced Samba dropping mounts? (NT shares).Everyone using smbfs I believe ...> again. But after an undetermined amount of time Samba just drops them again > and I have to remount them again. Does anyone know of a fix to this problem > (with the latest version)?I can right now remember 2 ways to get this. 1. If the server is down while someone is accessing the smbfs mount smbmount will terminate. Apply one of the "fixes" patches http://www.hojdpunkten.ac.se/054/samba/index.html 2. There is a signal related problem that will kill smbmount in some versions of the kernel. Upgrade to 2.2.18-preX or 2.4.0-test8 or later, those versions contain a workaround. If this is your problem you should get messages like this in your kernel log: smb_retry: caught signal If this does not match/work, come back with kernel version and kernel logs from when a mount stops working. /Urban
Urban, thnx for your reply. At the time of original post I was running kernel-2.2.14-5.0 and since recieving your reply I updated the kernel to the latest one I could find for Redhat which was kernel-2.2.16-3.i586....more below.... At Mon, 18 Sep 2000 14:51:54 +0200 (CEST), Urban Widmark <urban@svenskatest.se> wrote:> >On Mon, 18 Sep 2000 auto852@hushmail.com wrote: > >> Has anyone experienced Samba dropping mounts? (NT shares). > >Everyone using smbfs I believe ... > >> again. But after an undetermined amount of time Samba just drops them >again >> and I have to remount them again. Does anyone know of a fix to this >problem >> (with the latest version)? > >I can right now remember 2 ways to get this. > >1. If the server is down while someone is accessing the smbfs mount > smbmount will terminate. Apply one of the "fixes" patches > http://www.hojdpunkten.ac.se/054/samba/index.html > >2. There is a signal related problem that will kill smbmount in some > versions of the kernel. Upgrade to 2.2.18-preX or 2.4.0-test8 or >later,> those versions contain a workaround. If this is your problem you >should > get messages like this in your kernel log: > smb_retry: caught signal >If this does not match/work, come back with kernel version and kernel >logs from when a mount stops working. > >/Urban >Yep it's number two.... smb_retry : caught signal was the message I was getting in the logs: smb_trans2_request: result=-32, setting invalid smb_retry: new pid=21569, generation=2 smb_retry: caught signal smb_retry: signal failed, error=-3 last message repeated 8 times last message repeated 8 times last message repeated 11 times -multiple entries of course and a different pid number with each entry and the generation number increases. After updating the kernel I get really nice and simple error messages: kernel: smb_retry: caught signal kernel: smb_retry: caught signal kernel: smb_retry: signal failed, error=-3 last message repeated 4 times last message repeated 6 times last message repeated 3 times and one more glitch has occured since upgrading the kernel to 2.2.16-3.... which hadn't occured previously... now... on each reboot (during shutdown process) the system hangs while attempting to unmount the filesystem, so I have had to hard reset the system on each reboot. (Still running samba-2.0.7-4.i386 ) Any ideas? Suggestions? Any help would be greatly appreciated. Thnx
At Sun, 24 Sep 2000 20:52:43 +0200 (MET DST), Urban Widmark <urban@svenskatest.se> wrote:> >On Sat, 23 Sep 2000 auto852@hushmail.com wrote: > >> After updating the kernel I get really nice and simple error messages: >> >> kernel: smb_retry: caught signal >> kernel: smb_retry: caught signal >> kernel: smb_retry: signal failed, error=-3 >> last message repeated 4 times >> last message repeated 6 times >> last message repeated 3 times >> >> and one more glitch has occured since upgrading the kernel to 2.2.16- >3.... >> which hadn't occured previously... > >The "smb_retry: caught signal" problem should no longer occur in >2.2.18pre3 or so. You will probably not find a RedHat rpm for kernel >pre >versions so you may have to compile your own. > > >> now... on each reboot (during shutdown process) the system hangs while >attempting >> to unmount the filesystem, so I have had to hard reset the system >on each >> reboot. > >If you umount a smbfs share when the network has been downed the umount >will hang (there is no timeout on send or receives). It's known and >should >be fixed in recent distributions by simply moving the umount of smbfs >before shutting down the networking. > >smbfs should of course not require a working network to umount. > >Are you sure you didn't get this in 2.2.14 if you had smbfs mounted?Well...come to think about it...not 100% sure because a script was added to unmount and mount on a reboot and we had no need to reboot until updating the kernel. :) I hope that makes sense :) btw...just thought I'd say that I highly commend you on your dedication and helpfullness :)>/Urban >
At Sun, 24 Sep 2000 20:52:43 +0200 (MET DST), Urban Widmark <urban@svenskatest.se> wrote:> >On Sat, 23 Sep 2000 auto852@hushmail.com wrote: > >> After updating the kernel I get really nice and simple error messages: >> >> kernel: smb_retry: caught signal >> kernel: smb_retry: caught signal >> kernel: smb_retry: signal failed, error=-3 >> last message repeated 4 times >> last message repeated 6 times >> last message repeated 3 times >> >> and one more glitch has occured since upgrading the kernel to 2.2.16- >3.... >> which hadn't occured previously... > >The "smb_retry: caught signal" problem should no longer occur in >2.2.18pre3 or so. You will probably not find a RedHat rpm for kernel >pre >versions so you may have to compile your own.Yikes, I've never compiled a kernel before and in this case (from what I could see) it requires compiling pre-patch-2.2.17-20 (required for) then pre-patch-2.2.18-10 (was the latest I could see) by someone named alan. I've been a tech for over 6yrs and I've only just begun to learn linux. (slap me silly). :) Can those kernels be trusted? And any pointers towards information for how I would go about compiling a new kernel without messing up my existing one? (I understand LILO so that's cool but I can't afford to have the (production) server go down on me even for even a minute). I know it's a little off topic and I might be asking for too much but maybe if you could message me privately or something if it's not too much trouble? (as my right-hand helper has just gone on vacation for a week. (I promise not to harass you) hehe Oh how I wish there was a simple fix ;) thnx again.> >> now... on each reboot (during shutdown process) the system hangs while >attempting >> to unmount the filesystem, so I have had to hard reset the system >on each >> reboot. > >If you umount a smbfs share when the network has been downed the umount >will hang (there is no timeout on send or receives). It's known and >should >be fixed in recent distributions by simply moving the umount of smbfs >before shutting down the networking. > >smbfs should of course not require a working network to umount. > >Are you sure you didn't get this in 2.2.14 if you had smbfs mounted? > >/Urban >
>>The "smb_retry: caught signal" problem should no longer occur in >>2.2.18pre3 or so. You will probably not find a RedHat rpm for kernel >>pre >>versions so you may have to compile your own. > >Yikes, I've never compiled a kernel before and in this case (from what I >could see) it requires compiling pre-patch-2.2.17-20 (required for) then >pre-patch-2.2.18-10 (was the latest I could see) by someone named alan. >I've been a tech for over 6yrs and I've only just begun to learn linux. >(slap me silly). :) >Can those kernels be trusted? And any pointers towards information for how >I would go about compiling a new kernel without messing up my existing one?Having just got into this with Mandrake-lInux... I'll jump in here. First - downloading the latest kernel source 2.2.17, patching it to the latest 2.2.18-pre10 (or whatever) and recompiling is easy. I wouldn't do it on a production machine the first time, and I would have a good book to walk me through it (or the kernel how-to - see Linux Documentation Project at www.kernel.org). But I didn't have any problems, and I've only been using Linux for a couple of weeks. The hardest part is figuring out which options/drivers to compile in or leave as modules. Your best guide is probably the configuration file from your original installation. Second - Getting Lilo to boot your new kernel is also simple, as is cp to a newly formatted floppy and booting from there. Third - But running the new kernel within your existing installation can cause problems. I believe the RedHat install has around 40 different patches to it's vanilla kernel. Some of these (e.g. the Alan Cox or AC patches) may be included in the newer version of the kernel and subsequent patch that you applied. Many may not. As a result, your installation may not work properly, although you can probably use it to test the new kernel funtionality and bug fixes. Fourth - Unfortunately, running the new kernel may screw up your original installation when you revert to the original kernel. It did in my case. I had a Mandrake 7.1 installation which has upwards of 170 patches on the 2.2.15 kernel, bringing it to 2.2.15-4mdk. When I rebooted to the new patched kernel, I was missing supermount and some other functionality, but I could test how smbfs was working. When I switched back to the original kernel, supermount still wasn't working properly. I may end up re-installing (not a big deal as this is not a production machine). Fifth - it's a great learning experience <g> Bruce __________________________________________ Bruce LaZerte Grandview Lake in Muskoka Ontario, Canada
At Mon, 25 Sep 2000 08:50:53 -0400, Bruce LaZerte <mail@fwr.on.ca> wrote:> > >>>The "smb_retry: caught signal" problem should no longer occur in >>>2.2.18pre3 or so. You will probably not find a RedHat rpm for kernel >>>pre >>>versions so you may have to compile your own. >> >>Yikes, I've never compiled a kernel before and in this case (from what >I >>could see) it requires compiling pre-patch-2.2.17-20 (required for) >then >>pre-patch-2.2.18-10 (was the latest I could see) by someone named alan. >>I've been a tech for over 6yrs and I've only just begun to learn linux. >>(slap me silly). :) >>Can those kernels be trusted? And any pointers towards information >for how >>I would go about compiling a new kernel without messing up my existing >one? > >Having just got into this with Mandrake-lInux... I'll jump in here. > >First - downloading the latest kernel source 2.2.17, patching it to >the latest >2.2.18-pre10 (or whatever) and recompiling is easy. I wouldn't do it >on a >production machine the first time, and I would have a good book to walk >me >through it (or the kernel how-to - see Linux Documentation Project at >www.kernel.org). But I didn't have any problems, and I've only been >using Linux >for a couple of weeks. The hardest part is figuring out which options/drivers >to compile in or leave as modules. Your best guide is probably the >configuration file from your original installation. > >Second - Getting Lilo to boot your new kernel is also simple, as is >cp to a >newly formatted floppy and booting from there. > >Third - But running the new kernel within your existing installation >can cause >problems. I believe the RedHat install has around 40 different patches >to it's >vanilla kernel. Some of these (e.g. the Alan Cox or AC patches) may >be included >in the newer version of the kernel and subsequent patch that you applied. >Many >may not. As a result, your installation may not work properly, although >you can >probably use it to test the new kernel funtionality and bug fixes. > >Fourth - Unfortunately, running the new kernel may screw up your original >installation when you revert to the original kernel. It did in my case. >I had a >Mandrake 7.1 installation which has upwards of 170 patches on the 2.2.15 >kernel, bringing it to 2.2.15-4mdk. When I rebooted to the new patched >kernel, >I was missing supermount and some other functionality, but I could test >how >smbfs was working. When I switched back to the original kernel, supermount >still wasn't working properly. I may end up re-installing (not a big >deal as >this is not a production machine). > >Fifth - it's a great learning experience <g> > >BruceThanks Bruce, but yikes...it sounds to me like something I can't afford to do at the moment. As I don't have a spare box to mess with and what I am working with is a production server in a production environment what am I to do? Risk it all (a secure gateway and firewall setup) in order to "maybe" have Samba functionality? The system works great the way it is as a secure firewall and gateway but to get samba to "Maybe" work sounds to me like I might possibly have to re-install and redo the entire config just for a possible "maybe" samba will work. Doesn't quite sound worth the time nor the risk to me unless of course I was messing around..which is something I cannot afford to do at this time. .... Has anyone gotten Samba to work without any bugs whatsoever under Redhat 6.2 and Glftpd? What I need is stability, reliability, and no data corruption or bad crc's etc etc. I mean I could see what I can do about getting an extra machine together just to tinker with but at this time it is not in my budget and I need to know....is what I am attempting to accomplish -really- possible? But thnx again Paul, and Urban for your help. I do very much appreciate it.
At Mon, 25 Sep 2000 20:02:56 +0200 (CEST), Urban Widmark <urban@svenskatest.se> wrote:> >On Sun, 24 Sep 2000 auto852@hushmail.com wrote: > >> Yikes, I've never compiled a kernel before and in this case (from >what I >> could see) it requires compiling pre-patch-2.2.17-20 (required for) >then >> pre-patch-2.2.18-10 (was the latest I could see) by someone named >alan. > >The "someone named alan" is Alan Cox and he is the maintainer for the >2.2 >kernel series and gets to decide what goes in and not. > >You don't have to compile 2.2.17pre20 (which is the same as 2.2.17), > youThanks again Urb, :) ok well in alan's 2.2.18 kernel ftp dir there was/is a readme that says the patch is for 2.2.17.20 but anyways...we applied the patches 2.2.17-pre20 and then 2.2.18pre10 and recompiled the kernel but.... 1) the patches were looking for directories that didn't exist on Redhat 6.2 kernel 2.2.16-3 so we skipped passed them and recompiled the kernel the kernel anway. It looked like it patched quite a bit but after recompiling the kernel version hadn't changed. 2) I am still getting smb_retry errors in the logs and I am still losing mounts. 3) I also have a problem with the permissions changing after remounting. Half of the mounts permissions change for no reason while the other half of the mounts are what they are supposed to be. (and all the shares on the NT side have the same identical permissions). So....what now? It seems that it may be quite possible that alan's kernel patches are not quite compatible with Redhat 6.2 kernel 2.2.16-3 or 2.2.14 for that matter and I can't find any Redhat kernels any newer than 2.2.16- 3. Redhat 7 was just released tho and it is using kernel 2.4 and you had also mentioned kernel 2.4.0-test8 as a fix but what would be the point in wasting all that time re-installing if the 2.4.0-test8 patch is not compatible either? And is there anyone listening that is running Samba-2.0.7-4 with Redhat 6.2 (kernel 2.2.14 or 2.2.16-3) to map NT4 (SP-6a) shares -- successfully? Or maybe someone out there that is running Samba-2.0.7-4 with Redhat 7 to map NT4 shares -- successfully?>only have to patch it with pre-patch-2.2.18-10 and compile that. > >> Can those kernels be trusted? And any pointers towards information >for how >> I would go about compiling a new kernel without messing up my existing >one? > >You should of course not experiment on your production machines. One >problem may be if the kernel you normally run has extra patches not >included in the standard kernels and you depend on those changes. > >The pre versions are "steps" from one kernel version to another and >the reason for doing them is to get testing before calling it 2.2.18, > so >they may be seen as less safe than a 2.2.x version. > >More info: >http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html > >You probably want to copy the bzImage to a floppy (cp bzImage /dev/fd0) >and boot from that floppy. > >/Urban >
At Mon, 9 Oct 2000 14:11:45 +0200 (CEST), Urban Widmark <urban@svenskatest.se> wrote:> >On Sun, 8 Oct 2000 auto852@hushmail.com wrote: > >> Thanks again Urb, :) ok well in alan's 2.2.18 kernel ftp dir there >was/is >> a readme that says the patch is for 2.2.17.20 but anyways...we applied >the >> patches 2.2.17-pre20 and then 2.2.18pre10 and recompiled the kernel >but.... >> >> 1) the patches were looking for directories that didn't exist on Redhat >> 6.2 kernel 2.2.16-3 so we skipped passed them and recompiled the kernel >> the kernel anway. It looked like it patched quite a bit but after >recompiling >> the kernel version hadn't changed. > >If the kernel version doesn't change, then you are not running the new >kernel. > >The patch is not for a RedHat kernel. It is vs Linux kernel 2.2.17, >not >RedHat kernel 2.2.16-3, there is a difference. You probably (hopefully) >got a few errors compiling so it never actually built anything.nope amazingly enough there were no errors on the actual compile...it was just during patching that we had to skip past things the patches were looking for but didn't exist.>If I wasn't clear enough, I'm suggesting you build and boot a non-RedHat >kernel. Put the new kernel on a floppy or use a separate machine to >avoid >messing up your existing system.ok thanks for being clearer. :) I am still new to this stuff tho, so how exactly do I build a non-redhat kernel? I have someone with a few years of linux experience who has been helping out but he couldn't figure it out and samba is driving him nuts so he just wants us to build another system that recognizes larger drives instead (which we cannot afford at this time and either way I would like to get samba fully functional even if and when we build another box in the future) so could you do me/us a HUGE favor and point us in the right direction? please. :)>> 3) I also have a problem with the permissions changing after remounting. >> Half of the mounts permissions change for no reason while the other >half >> of the mounts are what they are supposed to be. (and all the shares >on the >> NT side have the same identical permissions). > >Please give an example of what the permissions were before and what >they >are after.before: drwxr-xr-x after: dr-xr-xr-x but this only happens with aproximately half of the mounted directories (out of aproximately 15 dirs) I have tried chmodding 777 all the dirs (after unmounting) and then remounting but same effect. The only difference between the mapped/mounted folders/dirs with the changed permissions and those that are not are all the folders with the changed/messed up permissions all begin with underscores. I hope that makes no difference. :)>/Urban >