little problem with logging on samba from os/2-warp

[Jacco de Leeuw]

>> I'm running the latest stable samba release 1.9.17 on a
>> linux-(2.0.29)-box. Samba is configured as a domain controller.
>> When I perform a domain-logon from one of our OS/2 Warp4 (peer)
>> workstations it takes a comparatively long time until it is successfull
>> completed. Anyway, i get an errormessage (NET8191) "Userdirectory could 
>> not be created".

Having squashed a couple of Samba/Warp interoperability problems (see my
homepage!), I recently dived into this matter as well. I can confirm this
problem. To my surprise however, domain logon scripts work fine!

(BTW, can anyone tell if the variable substitution %u is really supposed
to work? I had to revert to %U.)

>> This is very annoying and irritating to our employees (especially
>> because I get them _not_ to ignore errormessages).

And you're right about that :-)

>> Can anyone tell me, what this means and how to put that down.

Well, Samba implements domains in the Windows NT sense, and Warp seems to
expect it in the Warp Server style. Apparently there are some differences.
What I understand from it, is that Warp registers its name on domains according
to the RFC specs with nametype 0x00, while NT and Samba use the Microsoft
convention of nametype 0x1c. Perhaps somebody else can elaborate more on this.

A quick solution for your users would be to tell them not to use the
"LAN Server Logon" object, but the "File and Print Client Workstation Logon" 
(IBM Peer) object. You can spot the difference between the two from the number
of entry fields: the IBM Peer logon window does not ask for a domain name,
only for the login ID and the password. BTW, if you try to open the "File 
and Print Client Resource Browser" (IBM's counterpart of the "Network 
Neighbourhood") without first logging on, by default it opens the LAN Server 
login window. I haven't tested yet if using the "workstation logon" also means 
that logon scripts won't work anymore.

> you'll need to increase debug log levels, and probably run tcpdump -n -s 
> 1500 -w dump and then tcpdupm -n -s 1500 -r dump > dump.txt

I did some preliminary sniffing. I didn't see that many error messages in
log.nmb and log.smb, surprisingly. Only 2 "Unsupported API command" messages,
for LANMAN API 257 and 254. These seem to be WUserGetLogonAsn and
WAliasGetInfo, respectively. Whatever they do. See also:
http://microsoft.ease.lsoft.com/scripts/wa.exe?A2=ind9609C&L=cifs&P=R704
I haven't investigated yet what causes the long delay, but that should be the
easy part. To fix it is another matter.

Jacco
-- 
Jacco de Leeuw          | Fac. Phys,Math.&Comp Sc. | mailto:leeuw at wins.uva.nl
J.C. van Wessemstr. 54  | University of Amsterdam  | Maxer txtpager: 0660331048
1501 VM Zaandam, Holland<-Tel:+31(0)756352068| http://carol.wins.uva.nl/~leeuw/
  BIL9000: "I'm sorry Dave, but I can't let you go where you want to go today"