Hello, I am running Samba-2.2.0alpha-2 on a OpenLinux 2.3 (Caldera) system, and I was wondering if this error message is NORMAL behavior for a NT Server share mounted with the following command: //inet_server_1/C /mnt/server1 -o username=xxxxxxxx,password=xxxxxx,ip=x.x.x.2 here is what is in /var/log/messages: Mar 15 09:51:59 htmlodds kernel: smb_trans2_request: result=-32, setting invalid Mar 15 09:51:59 htmlodds kernel: smb_retry: sucessful, new pid=22605, generation=3 Now, in Samba-2.0.7, the response to a df -h message would be a input/output error on /mnt/server1, but in this case, it appears to have recovered the error on it's own (which is a good thing). df -h reports: Filesystem Size Used Avail Use% Mounted on /dev/hda1 6.7G 4.5G 1.8G 71% / //inet_server_1/C 3.9G 2.9G 1023M 74% /mnt/server1 now it would appear when it does have to establish a retry, the response back from df -h is one or two seconds slower. Has the use of smbmount/mount for accessing NT Server shares always been a problem when a idle condition has occured (at least to NT/Samba's way of thinking)? Any response you could provide would be useful, as we are trying to get away from being dependent on NT Servers. -Bill
Hello, I am running Samba-2.2.0alpha-2 on a OpenLinux 2.3 (Caldera) system, and I was wondering if this error message is NORMAL behavior for a NT Server share mounted with the following command: //inet_server_1/C /mnt/server1 -o username=xxxxxxxx,password=xxxxxx,ip=x.x.x.2 here is what is in /var/log/messages: Mar 15 09:51:59 htmlodds kernel: smb_trans2_request: result=-32, setting invalid Mar 15 09:51:59 htmlodds kernel: smb_retry: sucessful, new pid=22605, generation=3 Now, in Samba-2.0.7, the response to a df -h message would be a input/output error on /mnt/server1, but in this case, it appears to have recovered the error on it's own (which is a good thing). df -h reports: Filesystem Size Used Avail Use% Mounted on /dev/hda1 6.7G 4.5G 1.8G 71% / //inet_server_1/C 3.9G 2.9G 1023M 74% /mnt/server1 now it would appear when it does have to establish a retry, the response back from df -h is one or two seconds slower. Has the use of smbmount/mount for accessing NT Server shares always been a problem when a idle condition has occured (at least to NT/Samba's way of thinking)? Any response you could provide would be useful, as we are trying to get away from being dependent on NT Servers. -Bill
On Thu, 15 Mar 2001, Bill Parker wrote:> Mar 15 09:51:59 htmlodds kernel: smb_trans2_request: result=-32, setting > invalid > Mar 15 09:51:59 htmlodds kernel: smb_retry: sucessful, new pid=22605, > generation=3This is normal behaviour, and is not an error. The server disconnected, the client reconnects.> now it would appear when it does have to establish a retry, the > response back from df -h is one or two seconds slower. Has > the use of smbmount/mount for accessing NT Server shares always > been a problem when a idle condition has occured (at least to > NT/Samba's way of thinking)?alpha2 does not contain any direct changes to smbmount. It may be that alpha2 is doing something a bit faster and that it works because of that. There is one reconnect bug which is related to how long it takes for smbmount to reconnect. If it is too long then the retry fails (too long is currently 5 seconds). The reconnect business has always been problematic. It is not one single bug but a whole bug-nest. /Urban
On Thu, Mar 15, 2001 at 10:05:06AM -0800, Bill Parker wrote:> now it would appear when it does have to establish a retry, the > response back from df -h is one or two seconds slower. Has > the use of smbmount/mount for accessing NT Server shares always > been a problem when a idle condition has occured (at least to > NT/Samba's way of thinking)?I use autofs to mount my shares, the only drawback is that the password shows up in the logs. Is there some way to use smbmount without puting the password on the command line? Maybe something like ~/.smbauth? Would mount and smbmount have different interactions?> > Any response you could provide would be useful, as we are trying > to get away from being dependent on NT Servers. > > -Bill >We all hear you.