> Something else to try... Most of the reports I have gotten (with
> a few exceptions) the password was entered interactively at the password
> prompt. There are several other ways to enter the password. One is on
Add one in the non-interactive password column. I saw this with a share
left mounted overnight (last thing mounted).
Apr 14 16:31:26 cola automount[228]: attempting to mount entry /smbfs/d
(tcsh trying to autoexpand /smbfs/d . I have this thing about typing
<tab> after just about everything ...)
Apr 14 16:31:28 cola automount[14373]: >> Added interface ip=192.168.21.123 bcast=192.168.21.255 nmask=255.255.255.0
Apr 14 16:31:28 cola automount[14373]: >> Server time is Wed Apr 14 16:38:35 1999
Apr 14 16:31:28 cola automount[14373]: >> Timezone is UTC+2.0
Apr 14 16:31:28 cola automount[14373]: >> Domain=[SVTEST] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
Apr 14 16:31:28 cola automount[14373]: >> security=user
Apr 14 16:31:28 cola automount[228]: attempting to mount entry /smbfs/db
Apr 14 16:31:33 cola automount[14386]: >> Added interface ip=192.168.21.123 bcast=192.168.21.255 nmask=255.255.255.0
Apr 14 16:31:33 cola automount[14386]: >> Got a positive name query response from 192.168.21.9 ( 192.168.21.203 )
Apr 14 16:31:33 cola automount[14386]: >> Server time is Wed Apr 14 16:02:55 1999
Apr 14 16:31:33 cola automount[14386]: >> Timezone is UTC+2.0
Apr 14 16:31:33 cola automount[14386]: >> Domain=[SVTEST] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
Apr 14 16:31:33 cola automount[14386]: >> security=user
Apr 14 16:36:28 cola automount[14408]: expired /smbfs/d
...
Apr 15 09:18:58 cola kernel: smb_trans2_request: result=-32, setting invalid
Apr 15 09:19:04 cola kernel: smb_retry: caught signal
Apr 15 09:19:22 cola automount[228]: attempting to mount entry /smbfs/tek-prod
Apr 15 09:19:24 cola automount[19036]: >> Added interface ip=192.168.21.123 bcast=192.168.21.255 nmask=255.255.255.0
Apr 15 09:19:24 cola automount[19036]: >> Server time is Sun May 16 08:23:15 1999
Apr 15 09:19:24 cola automount[19036]: >> Timezone is UTC+2.0
Apr 15 09:19:24 cola automount[19036]: >> Domain=[SVTEST] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
Apr 15 09:19:24 cola automount[19036]: >> security=user
Apr 15 09:19:46 cola kernel: smb_retry: signal failed, error=-3
Apr 15 09:21:41 cola kernel: smb_retry: signal failed, error=-3
Apr 15 09:24:47 cola kernel: smb_retry: signal failed, error=-3
Apr 15 09:30:15 cola automount[19087]: expired /smbfs/tek-prod
Apr 15 09:30:15 cola kernel: smb_retry: signal failed, error=-3
Apr 15 09:30:15 cola automount[19087]: expired /smbfs/db
Apr 15 09:36:30 cola kernel: smb_retry: signal failed, error=-3
Apr 15 09:36:30 cola automount[19091]: expired /smbfs/db
(The tek-prod mount didn't fail, but it's in there so I'll leave it. Maybe
it helps you somehow.)
Here is a history of what I did:
58 9:19 cd /smbfs/tek-prod/Class\ Cast\ Exception/
(9:18 is probably when tcsh 'autoexpanded' "Class Cast Exception")
114 9:21 d /smbfs/db
(This gave the same I/O error as described previously by others)
115 9:40 umount /smbfs/db
116 9:40 mount
(umount worked)
117 9:40 d /smbfs/db/
(and this mounted the share again)
Servers are:
The 192.168.21.203 machine (db share) is a NT4 server with SP1 (yes, I'm
not kidding ... ). The other involved machine is a NT4 SP3 (workstation).
Linux 2.2.5
autofs 3.1.3
samba 2.0.3 (and I am sure of that)
glibc 2.0.7
> One last thing to try - and use this with caution - is to turn on
> SMBFS_DEBUG in the smbmount.c program and recompile it. I say use with
> caution because this WILL cause autofs and automount to hang if you are
> using smbmount with them. With SMBFS_DEBUG disabled, prompts and messages,
Too bad ...
I'll leave something open when I go home tonight and see if it happens
again. It never happens during my normal, daily use, which includes the
occacional mount of somthing from the SP1 machine.
/Urban
--- Urban Widmark urban@svenskatest.se Svenska Test AB +46 90 71 71 23
- 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/