Ok, here comes a bunch of pasting. I mounted, waited an hour or two,
and did the following:
##################################################################################
me2v:reliant me2v$ mount --type=smbfs
//WINNT/ME2V on /home/me2v/winnt type smbfs (0)
me2v:reliant me2v$ ls winnt
ls: winnt: Broken pipe
me2v:reliant me2v$ ls winnt
ls: winnt: Input/output error
me2v:reliant me2v$ ls winnt
ls: winnt: Input/output error
me2v:reliant me2v$ ls winnt
ls: winnt: Input/output error
me2v:reliant me2v$ ls winnt
ls: winnt: Input/output error
me2v:reliant me2v$
#############################################################################
Reading symbols from /lib/libresolv.so.2...done.
---Type <return> to continue, or q <return> to quit---
0x400a4237 in pause ()
(gdb) continue
Continuing.
Program received signal SIGUSR1, User defined signal 1.
0x400a4237 in pause ()
(gdb) continue
Continuing.
Program received signal SIGUSR1, User defined signal 1.
0x400afbe4 in __open ()
(gdb) continue
Continuing.
Program received signal SIGUSR1, User defined signal 1.
0x400afbe4 in __open ()
(gdb) continue
Continuing.
Program received signal SIGUSR1, User defined signal 1.
0x400afbe4 in __open ()
(gdb) continue
Continuing.
Program received signal SIGUSR1, User defined signal 1.
0x400afbe4 in __open ()
(gdb)
################################################################################
Mar 28 15:00:23 reliant kernel: smb_trans2_request: result=-32, setting invalid
Mar 28 15:00:40 reliant kernel: smb_retry: caught signal
################################################################################
Interestingly, the log only records the one try this time around. I
guess it's getting tired of recording the same old thing! ;). Anyhow,
I had to su to umount the directory.
Also of note, the *only* reason smbmount was running at this point,
was because gdb was attached to it. Once I detached from smbmount,
smbmount exited.
Something I tried, which was suggested by a person with the same
problem, on 2.0.3, was to do a 'df' on a regular basis, say every 2 or
5 minutes or so. I set it up as a cron job, but the other person
'daemonized' the process. The cron worked, I guess, but kept filling my
log with:
Mar 28 02:59:31 reliant kernel: smb_trans2_request: result=-32, setting invalid
Mar 28 02:59:32 reliant kernel: smb_retry: new pid=17246, generation=3
every time the cron job executed.
The other person set up an rc.<share>mount script in init.d, which
mounts the NT shares and sets up the 'daemonized' df. The df is:
/bin/sh -c 'while : ; do { df --sync --type=smbfs >/dev/null; sleep 123; }; done &'
As far as I can tell, the above doesn't generate any log entries, which
is good. It could probably be more efficient, but gets the job done.
This was from a person that needed 24/7 access to the NT shares without
a hiccup, and he said it's must be working for him.
Still, it's a kludge, and there should be a better way to make sure the
NT box doesn't disconnect, and the reconnects don't fail.
:: > I'll try it again with the password on the command line and see what
:: > happens.
::
:: You'll probably get the same results. At this point, the evidence
:: is pointing in a different direction.
::
Yes, I did.
:: This is getting curiouser and curiouser... /;-/
::
-- Matthew Vanecek Studies in Business Computers at the University of North Texas http://www.unt.edu/bcis Visit my Website at http://people.unt.edu/~mev0003 ***************************************************************** 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/