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

Hi,

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".
This is very annoying and irritating to our employees (especially
because I
get them _not_ to ignore errormessages).

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

Thanks.
-- 
.----------------------------------------------------------------------.
| Falk von Zydowitz                  H.Kaefer u. E.Maerz               |
| Systemverwalter                    OebVermIng im Land Sachsen-Anhalt |
| Tel: (03476) 894 302               Schlosstrasse 1 * 06333 Hettstedt |
`----------------------------------------------------------------------'

On Thu, 11 Sep 1997, Falk von Zydowitz wrote:
> Hi,
> 
> 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".
> This is very annoying and irritating to our employees (especially
> because I
> get them _not_ to ignore errormessages).
> 
> Can anyone tell me, what this means and how to put that down.
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

and check exactly what's going on.

luke

>> 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@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"