lkml.org 
[lkml]   [1999]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectsmbfs problem with 2.2.5
Since i'm using kenrel 2.2.5 a few days, i have major problems with
kernel smbfs. I'm using smbmount from samba 2.0.3. I made sure
that i removed all older versions of smbmount. But smbmount
doesn't seem to do any problems, mounting the shares works fine.
The remote machine is a windows nt server 4.0 / SP4.

When mounting shares, i can access them without problems, but
after some time ( not more than 5 or 10 minutes) i can't access
the shares anymore. Any access try results in a "i/o errror".

I know of no way to recover this situation. When trying to
smbumount/umount it, it get the same "i/o error". I have to su
to root and use umount to get rid ot the broken mount points.

As long as i used 2.0.36 in our hereogenous evironment i never
experienced such problems.

Below is a log which holds the error messages i got since my first
"i/o error" while accessing the shares. If someone needs more info
about the environment where i have this problem, just tell me what
you need.

thanks in advice,
Markus

ps: as i mentioned, shares disappeared after a few minutes.
i did some weird testing after writing the body of this mail:
i mounted two smb shares from our nt server, /smbmnt1 and
/smbmnt2 . i changed to /smbmnt1 and executed the following
command 'until false; do date; ls; sleep 3; done >~/smbcheck &'

after a while ( one houer) i checked back and :
/smbmnt1 was accessable without any errors
/smbmnt2 had the same "i/o error" as mentioned in the mail
body above.

weird fix, isn't it ? any ideas whats wrong ?

Is it normal to have a process
/smbmount //computer/share$ XXXXXXXXX -c 'mount /smbmnt1' -U user
in 'pause' state floating around ? This is only true for the
smbshare which did NOT disappeared after a few minutes.

is there a relationship betweens the smbmount process
floating around and the accessability to the shares ?


pss: i double checked also our network cables and links, there is
no problem with them

-- syslog --
Apr 13 09:42:29 ensrv01 kernel: smb_request: result -32, setting invalid
Apr 13 09:42:34 ensrv01 kernel: smb_request: result -32, setting invalid
Apr 13 09:42:35 ensrv01 kernel: smb_retry: caught signal
Apr 13 09:42:40 ensrv01 last message repeated 4 times
Apr 13 09:42:50 ensrv01 kernel: smb_retry: signal failed, error=-3
Apr 13 09:42:50 ensrv01 last message repeated 3 times
Apr 13 09:42:50 ensrv01 kernel: smb_request: result -32, setting invalid
Apr 13 09:42:52 ensrv01 kernel: smb_retry: caught signal
Apr 13 09:42:55 ensrv01 kernel: smb_retry: signal failed, error=-3
Apr 13 09:42:56 ensrv01 last message repeated 5 times
Apr 13 09:42:56 ensrv01 kernel: smb_retry: caught signal
Apr 13 09:42:56 ensrv01 kernel: smb_retry: caught signal
Apr 13 09:43:35 ensrv01 kernel: smb_retry: signal failed, error=-3
Apr 13 09:43:42 ensrv01 last message repeated 11 times
Apr 13 09:43:42 ensrv01 kernel: smb_request: result -32, setting invalid
Apr 13 09:43:47 ensrv01 kernel: smb_request: result -32, setting invalid
Apr 13 09:43:49 ensrv01 kernel: smb_retry: caught signal
Apr 13 09:43:54 ensrv01 last message repeated 3 times
Apr 13 09:44:03 ensrv01 kernel: smb_retry: signal failed, error=-3
Apr 13 09:44:04 ensrv01 last message repeated 3 times
Apr 13 09:44:54 ensrv01 su: (to root) mfischer on /dev/ttyp1
-- end --

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.111 / U:4.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site