> When the kernel goes to access an SMB share, and finds that the
> connection has died, it sends a signal to the smbmount process, which
> should be waiting around for exactly such a signal. When it catches it,
> the smbmount utility is supposed to re-establish the connection, and
> then pass that new connection info back to the kernel so that the
> operation can be retried.
>
> When people have reported this problem before, the answer returned by
> the developers seems to be "Well, we don't see that here. We can't
> reproduce the problem. Why don't you attach a debugger to your smbmount
> process, and when the problem happens, try to examine some variables and
> maybe give us a clue what might be going wrong?"
>
> And the answer from the community seems to be a collective "HUH??" and
> so, nothing happens that might fix the problem.
>
> Anyway, that's the way I see it.
In a personal message, Andrew Pimlott had the following diagnosis:
> The problem does not appear to be particularly subtle, to me. When smbmount
> mounts a filesystem, it goes into the background and the kernel signals it
> when it needs to reconnect. When you get the failure, you will notice that
> smbmount has died (that's what signal failed means). Clearly smbmount
> should never die, so simply figuring out why it is dying should point right
> at the problem.
>
> Andrew
>
So, a combination of the password problem and smbmount dying, maybe?
Although, I do notice PID regenerations in smbmount every now and
again. Perhaps it dies because the password is no longer cached? Going
the other direction (NT to Linux) never seems to fail, even after
rebooting Linux--the connection always seems to be there (hooray
samba!). Perhaps this is due to the way MS OSs maintain password
caches? Anyhow, if smbmount dies, then there isn't really any way to
reestablish the connection, because presumably the password cache dies
with it.
What about encrypting/storing password information in a user's
directory, readable only by the user? This would fail as a long term
solution, of course, due to security considerations and possibly the
logistics of implementation--for instance, you would have to track which
user had mounted the share last, so the remount would know where to find
the information...
Also, re debugging information, do you think capturing an strace of
smbmount from start to death would be of any use? I'll give it a shot
and see what happens.
-- Matthew Vanecek Course of Study: http://www.unt.edu/bcis Visit my Website at http://people.unt.edu/~mev0003 For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ***************************************************************** 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/