samba - Oct 1997 - Samba client behaviour during a fault condition? (PR#778)

> What happens if the samba server crashes (and reboots) during a
> client write (i.e. what state is the client left in?, can it recover
> the session and complete the write?, if so, what's the timeout value
> before this is no linger the case?)
To answer this I'll compare SMB with NFS.

NFS is a stateless protocol. The server keeps no state (in theory) about 
what clients are connected to it. Each request is treated as a separate 
entity. This means that if a server goes down the client can just wait
for it to come back up. This also implies that certain operations like
"open file" don't exist in NFS.

SMB is a "client recovery" protocol. This means that it is the clients
responsibility to store enough information about its current connections
to a server so that if the server goes down the client can re-establish
the connection transparently.

The problem with the client recovery model in SMB is that the client has 
to be very carefully written to achieve transparent recovery. Unfortunately
I don't know of any client that has been written this carefully. If the SMB
server dies while a Microsoft Office application is writing to a file, for
example, then you may get a nasty message on the client. You might even lose 
data. 

There is nothing that Samba can do about this really. All we can do is to try
to make Samba as robust as possible so that the number of times that a client
tries to recover is kept to a minimum. 
> What state is the server left in if the client gags during a write
> (or a read for that matter)?  Essentially, if a PC (or net
> connection) dies and doesn't gracefully terminate its net
> connections, how does the sabma server behave?
It notices the connection is dead and closes down the connection cleanly.
> One more thing, if one of our clients connects to the service using
> "\\servername\service" syntax, then the connection never
reconnects
> after a samba server reboot.  It does so with no problems if we use
> "\\serverip\service".  We use DNS for name resolution.  The error
we
> get is the infamous error 53 "network path not found".  This I
> haven't fully researched, I admit, but since I'm posting anyway ...
My best guess is that nmbd (which answers name queries) hasn't fully
started up when the reconnect request is made.

Either that or you have "dns proxy = yes" and nmbd is blocking on a 
DNS lookup so any other name queries that happen at the same time
get replies too late.

Andrew