RE: Samba can't keep NT shares mounted

Steve Rhodes (srhodes@cpinternet.com)
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/