[OpenAFS] strange issue with openafs on windows

Wed, 16 Sep 2009 09:27:02 -0700

--00032557f4ba7063bb0473b45e3d
Content-Type: text/plain; charset=UTF-8

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.

-- 
David Bear
College of Public Programs at ASU
602-464-0424

--00032557f4ba7063bb0473b45e3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We have noted that there is some strange side effect to openafs on windows.=
 Breifly, here is the scenario. Assume: 3 windows file servers -- sr=
v1, srv2, srv3. Assume: openafs 1.5.58, 1.5.59 and 1.5.60 clients ar=
e installed on windows XP, sp3. 
 found on XP clients with openafs that they were not able to make smb co=
nnections to srv2, but were able to make connections to srv1 and srv3. The =
error was something like path not found. Connection attempts were made usin=
g BOTH single host (netbios) name, aka \\srv2 AND FQDN, aka \\<a href=3D"ht=
tp://srv2.asu.edu">srv2.asu.edu</a>. 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 administra=
tor for srv2 and found that netbios of tcp was disable on that system. Afte=
r 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 correctl=
y 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 resolutio=
n 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 n=
etbios NOT be installed on they server, how does NETBIOS ont he server affe=
ct the way the client is able to resolve the name? It seems that openafs fo=
rces some difference in the way the server name is resolved in the smb conv=
ersation 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 everyon=
e&#39;s best interest.... when it becomes available. 
 -- David Bear College of Public Programs at ASU 602-464-0424<=
br>

--00032557f4ba7063bb0473b45e3d--