classicupgrade fails due to IDMAP version mismatch ?

Andrew Bartlett abartlet at
Fri Feb 15 15:26:41 MST 2013

On Fri, 2013-02-15 at 15:41 +0400, ?icro MEGAS wrote:
> Hello all,
> I am stuck on this problem. I have setup an isolated test environment containing the samba4 server, and three windows test clients. These 3 test clients are members of my old domain MYDOM at my Samba3 PDC. I moved them to my isolated test environment, because I want to perform a classic upgrade onto a new server. I have red the HowTo many times and did everything as described. As soon as I am doing this command on my samba4 server:
> "samba-tool domain classicupgrade --dbdir=/var/lib/samba
> --use-xattrs=yes /etc/samba/smb.conf"
> I get following error at the end (see
> RiXtEr told me to remove or rename /var/lib/samba/winbindd_idmap.tdb.
> I did so by rename it to /var/lib/samba/winbindd_idmap.tdb.OFF
> After this change I removed /usr/local/samba/private
> and /usr/local/samba/etc and did rerun the classicupgrade command. 
> The resulting ending line of the classic domain upgrade was:
> set_nt_acl:
> chown /usr/local/samba/var/locks/sysvol/{6AC1786C-016F-11D2-945F-00C04FB984F9}/MACHINE. uid = 0, gid = 512.
> But the problem is that my test clients cannot logon to the new samba4
> server, although all the tests described in the HowTo were OK. I also
> can access from the windows test clients the share on \\samba4
> \netlogon and also \\\netlogon or even the sysvol share works, too.
> If on the windows client, I change the computer membership to
> WORKGROUP, rebooting, and then joining again to MYDOM it works. The
> windows client is registering correctly to the samba4 server and I can
> use the domain. But thats not intended, because normally one would
> expect, that the client can logon to the new samba4 server as I did
> the classis upgrade migration to a new server.
> I am really stuck with that problem, and do not know why:
> 1.) the classicupgrade fails with the above showed pastebin (UNCAUGHT

This seems to be related (we won't know until someone supplies us with
the output of tdbdump on that file, even if only of any VERSION keys) to
having an empty DB.  We have an idea how we could rework this code, just
haven't started on the task.  We know this hits a number of users. 

> 2.) and why the windows cannot logon to the new samba4 server after
> the classicupgrade.

This is the more serious issue.  We need to work out why the client no
longer shares a valid machine account password with the server.

To diagnose this further, I'll need logs from the AD DC, and the output
of this command:

bin/smbclient4 -L server -k yes -Uadministrator%password

This will help me know in what way this is failing.  A network trace of
this and the failed client login might also help:


Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list