As a consultant in the Novell-related side of things, I have configured a handful of OES2 Linux servers to be Samba-aware for the end-users. But for some reason, I always forget one particular step. And I figured that if I wrote a post about it, it would make me remember. Think it will work? Only time will tell….
Anyway, the general steps to samba-enabling an OES2 user is like this:
- Create an NSS volume if you didn’t already
- Configure Universal Password for the users/containers that need to use Samba
- Configure that NSS volume for Samba if you haven’t already (shares and users)
…okay, that’s easy enough. But the step I always forget happens only when I’m in a hurry, and am just enabling Universal Password with the defaults, just until I can go over the finer points of the policy with the customer. Because the “defaults” of a new Universal Password will not allow samba to work; you *must* enable one non-default thing in the policy:
- Allow admin to retrieve passwords
…or you will get an error when trying to Samba-enable the user. The error will be something like this:
“Could not Samba enable the user for group, (windows name)-W-SambaUserGroup”
Of course, I need to clarify that I only have this problem when in a rush… I’m a nice, diligent, thorough consultant who usually designs, configures, and deploys a Universal Password Policy with a customer, in a test-bed, well in advance of deploying Samba… You believe me, don’t you?
😉