Messages in this thread |  | | Date | Tue, 13 Apr 1999 16:28:43 +0200 | From | Markus Fischer <> | Subject | smbfs 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/
|  |