[OpenAFS] strange issue with openafs on windows

[Jason Edgecombe]

David Bear wrote:
> We have noted that there is some strange side effect to openafs on windows.
> Breifly, here is the scenario.
>
> Assume: 3 windows file servers -- srv1, srv2, srv3.
>
> Assume: openafs 1.5.58, 1.5.59 and 1.5.60 clients are installed on windows
> XP, sp3.
>
> found on XP clients with openafs that they were not able to make smb
> connections to srv2, but were able to make connections to srv1 and srv3. The
> error was something like path not found. Connection attempts were made using
> BOTH single host (netbios) name, aka \\srv2 AND FQDN, aka \\srv2.asu.edu.
> Note that srv2 would respond to pings, both by IP address and FQDN. FQDN
> requests were resolved from DNS.
>
> If we removed openafs from the windows clients, they were able to make smb
> connections find to srv2.If we loaded openafs back on the system, they again
> failed.
>
> Later we were able to talk with ther server administrator for srv2 and found
> that netbios of tcp was disable on that system. After he enabled it, the
> systems again were happy making connections to srv to even with openafs
> installed.
>
> I send Jeff Altman a message relating part of this tale and he correctly
> stated that it was a name resolution issue. However, the issue seems more
> complex. First, why does existence of openafs cause the client to fail to
> resolve srv2 by name? what could it possibly have to do with name resolution
> on the client. Note that netbios of tcp IS enabled on the client. Second,
> since the comon failure requires BOTH openafs on the client AND TCP over
> netbios NOT be installed on they server, how does NETBIOS ont he server
> affect the way the client is able to resolve the name? It seems that openafs
> forces some difference in the way the server name is resolved in the smb
> conversation the client generates. Why would netbios on the server affect
> they the client resolves the name?
>
> Finally, if the native file system driver version of openafs that does not
> require the microsoft smb server would fix this kind of strange issue, it
> seems that moving to that version with all due speed would be in everyone's
> best interest.... when it becomes available
Everyone agrees that the native filesystem driver is the best way to 
proceed, but we are lacking the resources to go there quickly. Jeff 
Altman can provide more details.

Jason