I just upgraded Samba from 3.0.7 to 3.0.8. Last version chenges secrets.tdb location from /etc/samba/private to /var/lib/samba/private. Almost immediately I got NT4 users complaining they couldn't log in the domain (Samba acts as PDC), instead 9X/2000/XP users had no problems logging in, just problems with shared printers. After quite lot of time spent in investigations I found the problem it was a very obvious one: the secrets.tdb in /var/lib/samba/private was not my original one, but a new one that was created on the fly immediately after starting 3.0.8 version. Reproducible: Always Steps to Reproduce: Upgrade to Samba 3.0.8 or higher from any previous version (maybe just 3.0 series? was secrets.tdb in /etc/samba/private in 2.2 series too?) Actual Results: New domain SID Expected Results: I think it would be a very good idea to include a simple check in the ebuild: if ((exists /etc/samba/private/secrets.tdb) and not (exists /var/lib/samba/private/secrets.tdb)) then mv /etc/samba/private/secrets.tdb /var/lib/samba/private
I had to go back to samba-3.0.7-r1 for now as moving the secrets.tdb file did not solve the issue for me. I need the use of my printer.
I think a 'net getlocalsid [domain name]' and 'net setlocalsid [the previous output]' could restore the old infos. Win 9x/Me (and perhaps other client versions) printing issues are addressed in 3.0.8-r1. The upcoming 3.0.9 has the external patch already included. For the move, this could be unsafe in case old samba is in execution while doing the emerge process. A symbolic link could be made, of course, but old SID is anyway recoverable through the 'net *sid [...]' commands above. We will think about this, anyway... Maybe a 'cp'?
About the SID (I don't use Samba as a print server so I don't know anything about print problems): getlocalsid and setlocalsid read/write on the sectets.tdb file that stays in the directory pointed by the "private dir" smb.conf parameter: in 3.0.7 "private dir" default value is /etc/samba/private, in 3.0.8 is /var/lib/samba/private. Now, if you are currently running 3.0.7, you can: 1) do a getlocalsid 2) take note of the SID 3) stop samba service 4) emerge 3.0.8 5) etc-update 6) start samba service 7) do a setlocalsid using the previously annotated SID 8) restart/reload samba service Or you can (simplier): 1) stop samba service 2) emerge 3.0.8 3) etc-update 4) copy/move secrets.tdb from /etc/samba/private to /var/lib/samba/private 5) start samba service What I mean is that getlocalsid and setlocalsid are better used for other jobs, such as migrating from a Linux to a Windows PDC or viceversa. Moreover you say "A symbolic link could be made, of course, but old SID is anyway recoverable through the 'net *sid [...]' commands above": this will only work if you do the getlocalsid while running 3.0.7 and setlocalsid while running 3.0.8, otherwise you will read and write the same secrets.tdb file. What I propose is to go with the "cp" (you're right, better avoid "mv"), still applying the if/then check in my first post. The check is needed to avoid something like this: 1) I run 3.0.7 with "foo" SID 2) I upgrade to 3.0.8: "foo" SID is copied to /var/lib/samba/private 3) I change domain name, my new SID is "bar" 4) I upgrade to 3.0.9: the old "foo" SID (from 3.0.7 times) is copied to /var/lib/samba/private overwriting my new "bar" sid The if/then check would avoid previous situation.
ok: in cvs. Anyway, by temporarily making unaccesible (moving/renaming) the local sid, the 'net getlocalsid [domain]' forces the sid to be rebuild (in case you lost it).
