Samba
Warning: rant ahead
Someone decided that doing a Windows-specific protocol would be a good idea. Whoever this person is, I hope he rots in hell. But that's not what this post is about.
Someone else decided that doing a free software implementation of that Windows-specific protocol would be a good idea. Hence samba was born. And all was good.
For the next few years, Samba kept implementing more and more features of that particular Windows-specific protocol, which kept getting changed and renamed over the years. Originally, samba could just export files, and you could specify whether users could or could not write to your files. Perhaps it already had passwords at that point—not sure. Later, usernames were added, and the ability to join a Windows domain, and then another type of Windows domain, and eventually a number of other differently deficient difficulties.
As these things were implemented, the ways of configuring samba to properly do all these things was made more and more complex, to the point where it now no longer seems possible to install samba without major repercussions on the 'plain' Linux installation. A bit like having an apache requiring you to add apache-specific usernames through an apache-specific NSS module (winbind anyone?) just so you could export ACLs. Oh, and forget about retaining your existing usernames.
Now I'm not sure whether this is related to a) me having tried winbind at some point in the past, deciding that I didn't like the effects it had, and removing it again (with as a result that it left some traces on the system), b) the system being joined to an ADS domain which might have some special requirements, or c) this particular system having a bit of a weird history that might have fucked up some of the internal state files of samba; but at any rate, it sucks.
It seems to me that somehow, over the years, samba has lost the ability to just function as a minor something that just happens to be one service on a machine—much like apache on my laptop—and now requires one to do a complete overhaul of the entire system. That's just stupid; I am not going to migrate users to their winbind counterparts, thankyouverymuch.
Stupid ********
Of course, though unlikely, it's not impossible that I've missed something. But at any rate, even if that is the case, the hoops one needs to jump through to get to the above situations are far too numerous and complex.
There is a good text written some time ago about SAMBA configuration, with a short but working example:
http://www.linuxfromscratch.org/blfs/view/svn/server/samba3.html
Your problem is that you are taking the default example configuration file too seriously. Just disregard it, write your own from scratch. It will be short and functional.
Another problem is that you are trying to impose different requirements on today's SAMBA and on old versions. You are now trying to allow every Windows user use his domain username and password seamlessly to connect to the server, but forget that in good old days this was impossible. And we remove that requirement, we end up with practically the same simple configuration as in the URL above.
"I am not going to migrate users to their winbind counterparts, thankyouverymuch."
And you should not have to. Something is very wrong.
Samba on my servers and workstations, attached to an active directory domain, allows Squid to authenticate Windows users and allows me to use Windows users and groups for file shares.
But it does not affect my local users at all, including ACL support for local users.
Perhaps you had winbind integrated with PAM at one point, and forgot to remove it?
man, calm down! samba is actually a really cool piece of high quality software and for sure better than NFS. and by the way: how are gonna talk to all these shiny little wondoze boxes on your network without it?
Nit: SMB wasn't invented by Microsoft or first used on Windows, although they have extended it far beyond its origins.
Samba plays well with Linux if you're using it as the domain controller; things get worse if you're joining an existing domain. Part of the problem is AD uses Kerberos, which really is a system-wide change. http://wiki.samba.org/index.php/Samba,ActiveDirectory_&_LDAP uses a separate OpenLDAP directory to avoid using winbind.
You should see the nasty hacks ZFS has for SMB support - they use negative uids for ephemeral users.