The Samba-Bugzilla – Bug 892
expsam mysql usermanager error's
Last modified: 2005-08-24 10:19:54 UTC
this problem/bug is prob. already known... but still.
when fireingup anny usermanager within a NT enviremnt.
the manager gives back a:
"STUB RECEIVED BAD DATA" and/or "ARRAY BOUND ARE INVALID"
this only happens, with the mysql plugin.. (as far as i tested)
i tryed the tdbsam, and there it works all fine.. (so no worry there)
it's prob. a small typo error with assigning the expsam orso ?? (dunno)
(don't think it's the actual sql plug in)
the rest of the mysql plugin works fine
Collen Blijenberg (MLHJ)
Somehow, i think the problem of this bug is not the mysql-plugin.
we tested it several way's, and in ethereal dump's & debug log's
it show's that the sql data get's send, but i gues not i the right way.
there for it might be possible that the bug is where the plugin get's called,
or where the plugin data get's handled... ???!?
dunno, just doing sugestions...
The bug is certainly not in the passdb code (the code you are referring to),
since this code is exactly equal when using tdb or mysql.
The bug is either in the mysql plugin or caused by illegal data in the MySQL
Jelmer, what's the resolution on this one ?
> As far as i know, it's still open...
> the bug still exist within samba 3.0.2
> can't seem to find the cure...
replease retest against 3.0.11.
Well i upgraded the network (pdb and bdc) to 3.0.11 version.
but the bug is still there. stub received bad data.
staingely the network works fine, users can login, i get home dirs and profiles
it's just when i try to get, the Fullname or Description or some other data,
that stupid stub error pops up.
same with the MS usermanager from nt4, i get an overview from the users and
groups. clicking on a group works, klicking on a user for the userinfo fails.. ?
so the issue is still there. i'm wondering if other exp_backends have the some
jelmer, please fix this or mark as won't fix. You're call. No one
else is maintaining these modules.
This error was raised whenever unknown_6 (size_is?) was lower then hours_len
(length_is?). Fixed by setting the default for unknown_6 to 1260, which
apparently is what tdb uses.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.