Messages in this thread | | | From | Steve Rhodes <> | Subject | RE: Samba can't keep NT shares mounted | Date | Wed, 22 Sep 1999 08:17:08 -0500 |
| |
I read through a bunch of posts on the subject, and I have seen a number of theories that the problem might be caused by a period of inactivity, rather than heavy network load as I earlier speculated. I thought an easy test would be to mount the NT box, then physically disconnect the smbmount client for a period of time, and see if the connection breaks. Well, I left it off the network all night, and when I re-connected and checked it this morning, it was still running!
I also ran a quick test by running a ping flood over the network. The collision light on the hub was blinking madly, and I still could not induce failure!
I am starting to think that it may have something to do with the configuration of the NT box. I am running this one as a Primary Domain Controller. I recall from my earlier experience that the machine in the troubled network was a Stand Alone configuration. (Un)fortunately, that machine has been re-configured as a Linux box (DHCP problems).
Still trying,
Steve Rhodes
-----Original Message----- From: Matthew Vanecek [SMTP:mev0003@unt.edu] Sent: Tuesday, September 21, 1999 9:06 AM To: srhodes@cpinternet.com Cc: 'Urban Widmark'; 'Khimenko Victor'; linux-kernel@vger.rutgers.edu; samba@samba.org Subject: Re: Samba can't keep NT shares mounted
Steve Rhodes wrote: > > Bad news guys, > > Almost 24 hours and I can't get smbmount to fail! I connected another > Win98 machine to the subnet, but apparently, it's not enough to cause the > smbmount problem to occur. > > I am going to try flooding the network with netbios packets and see if that > can induce failure.
FWIW, it never occurs here when the net is under load. Generally, it's just when it's idle, and smbmount dies for some reason. I think that's where we need to focus--when is smbmount dying, and why? Is it a result of something NT does? /var/log/messages and /var/log/samba/* don't have a clue as to why it dies.
Maybe it's a problem specific to NT? Or to NT Workstation? That's what I have, NT 4.0 WS SP5. I don't have a Windows machine to test on (thank God!! It's enough to have it at work!).
Anyhow, I took the smbmount from 2.0.5a and recompiled it. In the top, I uncommented the SMBFS_DEBUG portion. Doesn't really help, I don't think, but...
At the beginning of the day yesterday, I mounted a share with the DEBUG-enabled smbmount, and I mounted another one with the normal smbmount. WHen I got home from work, the DEBUG-ed share was still mounted and up (well, aside from pagefile.sys ;) ). THe normal smbmount was out like a broken lamp. df hung for a bit while it tried to probe that mount point, then I got the infamous input/output error. Here's what happened when I do a df:
Sep 21 08:49:30 reliant kernel: smb_trans2_request: result=-32, setting invalid Sep 21 08:49:31 reliant kernel: smb_retry: new pid=19481, generation=7 Sep 21 08:49:31 reliant kernel: smb_lookup: find //pagefile.sys failed, error=-2 6 Sep 21 08:49:34 reliant kernel: smb_retry: signal failed, error=-3 Sep 21 08:51:50 reliant kernel: smb_retry: signal failed, error=-3
The first part, up to and including the pagefile.sys message, is from the smbmount with "#define SMBFS_DEBUG 1". The last two are from the regular smbmount, or from smbfs trying to awaken the dead normal smbmount, I guess, is more accurate.
I haven't had time to decode what extra stuff gets done with SMBFS_DEBUG. There's a bunch of "#ifndef SMBFS_DEBUG"s in there, though...
I'll probably try to attach a gdb to the regular smbmount tomorrow morning (no time today), and see what happens.
-- Matthew Vanecek Course of Study: http://www.unt.edu/bcis Visit my Website at http://people.unt.edu/~mev0003 For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ***************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |