A few nights ago I decided to upgrade the Debian installation on my home server. I backup all the important stuff nightly, so I wasn't too worried. However, I did take a lot of care following along with the upgrade process and intervening when needed.

Now, this server is pretty important to my home network. It serves time, dhcp, nameservers and most importantly it runs samba to act as the Primary Domain Controller for my home Windows domain. All the windows boxes, as well as the Infrant NAS are clients in this domain.

You might remember my post from last November describing the setup.

Anyhow, it was the first thing I checked.

Main Vista client still on domain? Check. Can log in? Check. Can browse the domain? Check.

Can mount the photo share from the NAS? Nope.

No logon servers available.

Ack!!!

Now I'm worried. No matter what I do, I can't mount a share from the NAS on any Windows or Mac box.

Ok, over to linux and dig out smbclient.

NTSTATUSNOLOGONSERVERS.

After some groveling around I figure out that it's a problem with the NAS. Leave domain. Join domain. It all works, but I just can't see the shares. I turn to Google. “Samba 3.0.23 NTSTATUSNOLOGONSERVERS”. Nothing of use turns up.

Next step.

I download the source to Samba 3.0.26a, the latest rev, build it and install it side-by-side. This way I can switch between the two revisions, so I decide to bring the domain up completely fresh in the new installation.

I can use “net getdomainsid” and “pdbedit -u user -v” to get all the old SIDs and RIDs, so hopefully everything will match in the new domain.

It all works perfectly - machines join the domain; users can login with the same SIDs (this is important so that all the old permissions still work).

Can I see the shares on the NAS?

Nope.

Ok then. Lets downgrade the distribution's samba package to the previous version (3.0.14a).

Now we're screwed. It can't access the password database.

Ok, so the distribution's samba install is dead. I uninstall it and run with the source-built version in /usr/local/samba.

Now we're back to a state with fresh source and everything working except the NAS shares.

Bump up the debug level. Try connecting. Everything is working. No errors from Samba, but the NAS is still horked.

Ok, lets scour the docs carefully… Nothing.

More searching reveals the following in the Infrant forums:

I have a ReadyNAS running RAIDiator 3.01c1-p4 it's a member of a domain “CLOUDVIEW”. The PDC is a FreeBSD box running samba 3.0.23c.

It used to work. However I updated my samba build on the PDC and I now get this

jeeves# /usr/local/bin/smbclient \\\\filestore\\ -U jpp

Password:

session setup failed: NTSTATUSNOLOGONSERVERS

jeeves#

and syslog on the PDC show this

Dec 6 00:24:37 jeeves smbd 31622: [2006/12/06 00:24:37, 2] auth/auth.c:checkntlmpassword(309)

Dec 6 00:24:37 jeeves smbd 31622: checkntlmpassword: authentication for user [jpp] -> [jpp] -> [jpp] succeeded

Dec 6 00:24:37 jeeves smbd 31622: [2006/12/06 00:24:37, 2] auth/auth.c:checkntlmpassword(309)

Dec 6 00:24:37 jeeves smbd 31622: checkntlmpassword: authentication for user [jpp] -> [jpp] -> [jpp] succeeded

What changed and how to I get access to my data again?

Sounds familiar. What's the resolution?

After a lot of digging around I fixed it. During the upgrade of samba to .23c (now d) my PDC somehow “lost” the group mappings - this effectively left my network with no “Domain Admins” “Domain Users” or “Domain Guests” groups.

Re-creating those group mapping with the correct RID's fixed the issue.

Ok, there's a lead. “net group” shows no groups on my machine and “net groupmap” shows no NT to unix mappings. Could the NAS be looking for the “Domain Users” group (as it exports a share for each user) and as it can't find it, failing with a weird error?

After much documentation reading, I find out that this is actually by design! Prior to 3.0.0.23, those very important groups were generated automatically by Samba. With 3.0.0.23, they go away and it's up to the admin to create them!

Doesn't sound like a minor-minor-point release change to me.

Anyhow, I came up with the following:

# net groupmap add ntgroup=“Domain Admins” unixgroup=ntadmins rid=512 type=d

  1. net groupmap add ntgroup=“Domain Users” unixgroup=users rid=513 type=d
  2. net groupmap add ntgroup=“Domain Guests” unixgroup=nogroup rid=514 type=d

Can I connect to the NAS?

YES!!!

That was it.

Man did that suck.

What sucks even worse is the fact a minor-minor-point release upgrade horks backward compatibility in such an unpleasant fashion and, as far as I can tell, without calling attention to it in the upgrade process. The only relevant documentation I can find about this in the “Note” in the samba 'how to' docs

Versions of Samba-3 prior to 3.0.23 automatically create default group mapping for the Domain Admins, Domain Users and Domain Guests Windows groups, but do not map them to UNIX GIDs. This was a cause of administrative confusion and trouble. Commencing with Samba-3.0.23 this annomaly has been fixed - thus all Windows groups must now be manually and explicitly created and mapped to a valid UNIX GID by the Samba administrator.

This ain't exactly calling the problem to attention…

Anyhow, hopefully this rambling post will be of some help to others in the future.

Oh, and don't get me wrong - I love samba. I just feel a little jilted :-)