Samba 4.1.6 not working after upgrade from 3.6.x - Fedora 20

[Gerhard Wiesinger]

On 17.03.2014 21:13, Alexander Bokovoy wrote:
> Hi,
>
> On Mon, Mar 17, 2014 at 8:01 PM, Gerhard Wiesinger <lists at wiesinger.com> wrote:
>> Hello,
>>
>> I upgraded from Fedora 17 (Samba 3.6.12) to Fedora 20 (Samba 4.1.6) and some
>> shares are not working any more (I'm asked for password or not accessible
>> message). I did not change anything in the config and the config is the same
>> as in Fedora 17.
>>
>> After some debugging I found the following error messages:
>> ../source3/smbd/service.c:612(make_connection_snum)
>>    Connect path is '/shares/mm' for service [mm]
>> ../libcli/security/dom_sid.c:208(dom_sid_parse_endp)
>>    string_to_sid: SID @users is not in a valid format
> I don't think this is an issue per se. The message is harmless in your
> context. What happens is the following. When share connection is
> established, we do number of checks and calculate access mask for the
> user in check_user_share_access(). The first thing
> check_user_share_access() does is to call to user_ok_token(). The
> latter actually verifies user name against list of invalid and valid
> users. When going through the lists, we try to take each element of a
> list and convert to SID. If that succeeds, we do check on the SID
> instead of going to a more resource-consuming path of name to SID
> conversion.
>
> If that element is not a SID already, we do group checks through
> various methods. But before that, SID conversion will already complain
> to the logs that "SID <element> is not in a valid format". This is
> what you see in the log above.
>
> If your share access is denied, it is some other check that is
> failing. I can reproduce string_to_sid complaint too but for me
> accessing a share with 'valid users = @users', where users is a group
> that user belongs to, works fine. To get more detailed answer I'd need
> to see more logs.
>
> Perhaps we could raise the level at which string_to_sid() issues its 'error'.

Hello Alexander,

I found the problem: Samba 4 behaves differently than Samba 3.6.x: If 
"force user" is used in Samba 4 it must be also on the valid users list. 
If not, access is denied.
In Samba 3.6.x this wasn't necessary.

NOK:
         valid users = @users
         force user = apache
OK:
         valid users = @users apache
         force user = apache

So this is either a bug or at least it should be documented as a 
different behavior in Samba 4 (with a big explanation marks).

Thank you.

Ciao,
Gerhard

10, pid=19758, effective(0, 0), real(0, 0)] 
../source3/smbd/share_access.c:215(user_ok_token)
   User apache not in 'valid users'

# NOT OK
[mm]
         path = /shares/mm
# Causes problems here
         valid users = @users
         write list = gerhard
         force user = apache
         force group = apache
         create mask = 0644
         hide dot files = No

# OK
[mm]
         path = /shares/mm
         valid users = @users apache
         write list = gerhard
         force user = apache
         force group = apache
         create mask = 0644
         hide dot files = No