samba - Feb 2014 - Odd "force user =" behaviour in 4.2.0pre1-GIT-0ce4631 on "Solaris".

Good day everyone,

 

                So here's a strange thing .

                Thought I'd update my Samba (client code only) installation
in case some of the things I've been involved in discussing have had their
fixes make their way into the code base yet (not logging the million-and-one
"accept()" errors which crop up on Solaris at debug 0, and correctly
interpreting the Kerberos PAC).

 

                Unfortunately those fixes don't seem to be in there at the
moment - never mind, I'm sure they will be at some point.

                However, this release has shown up a very odd little
problem.  I'm quite happy to perform diagnoses to try and get to the bottom
of it, but I'll wait until someone suggests what - I don't think merely
turning on full debug and pasting everything into this is going to be useful
.

                The problem:

 

                On some of our shares, I use the "force user ="
functionality; on others I also use "force group =", but that
doesn't seem
to be causing any issues.

                This has always worked fine, however on this release, any
share which uses "force user =" cannot be accessed from any client -
it
results in a "The security ID structure is invalid" message on the
client
and no access to the share.

                What's *really* odd is that if I comment out the "force
user
=" line (and re-start everything Samba for good measure, even though I
probably don't need to), everything works, but the forced user is still
actually forced!

                I.e.:

 

[someshare1]

                comment = Some random share #1

                path = /var/tmp/someshare1

                force user = administrator

                force group = users

                read only = no

                browseable = yes

# This fails with a "The security ID structure is invalid" error.

 

[someshare2]

                comment = Some random share #2

                path = /var/tmp/someshare2

#             force user = administrator

                force group = users

                read only = no

                browseable = yes

# This works, and any user creating a file/directory under
"/var/tmp/someshare2"

# gets it created owned by "administrator" with group
"users"?!

 

                So it looks as though it might be some relatively
straightforward problem parsing "smb.conf", except that quite what a
not
commented "force user =" turns into which causes a security ID
structure
error I have absolutely no idea!

 

                As I said, odd .

 

                Cheers folks,

 

                Tris.

 

Ps.  Yes, I know there are other options rather than using "force user
=".
However in this case, it's the simplest and most efficient approach as the
directory structures underneath these particular shares need also to be
manipulated by Unix scripts which I'm not about massively to re-write to
understand ACLs .  The "force group =" I could (and actually do) work
around
with the SGID bit on the top-level directory (and, by extension, any
directory below it), but that's not the issue - "force group ="
still seems
to work correctly!