[Samba] [SOLVED] Samba4 Does cifs need a keytab for the multiuser option?

[steve]

On 12/04/13 17:21, Rowland Penny wrote:
> On 12/04/13 12:48, steve wrote:
>>
>> On 12/04/13 13:10, Rowland Penny wrote:
>>> On 12/04/13 08:32, steve wrote:
>>>> On 12/04/13 08:06, steve wrote:
>>>>> On 11/04/13 22:45, steve wrote:
>>>>>> On 11/04/13 22:05, Rowland Penny wrote:
>>>>>>> On 11/04/13 20:42, steve wrote:
>>>>>>>> On 11/04/13 20:39, Rowland Penny wrote:
>>>>>>>>> On 11/04/13 17:27, steve wrote:
>>>>>
>>>> Hi again
>>>> This is driving me crazy!
>>>> If I change the permissions on the cifs share to 0777, I can then 
>>>> write to the cifs share as user steve2 BUT the uid:gid sent by cifs 
>>>> are wrong:
>>>>
>>>> -rw-r--r--  1 3000032 20513 0 Apr 12 09:25 j2
>>>> -rwxrwxr-x+ 1 3000017 users 0 Apr 12 09:25 j3
>>>>
>>>> The file j2 was created on the unmounted share with the correct 
>>>> uid:gid, 3000032:20513
>>>> The file j3 was created on the cifs mounted share. The server has 
>>>> sent 3000017:100 :(
>>>>
>>>> Any ideas?
>>>> Cheers,
>>>> Steve
>>>>
>>>
>>> OK Steve, after some investigation, either I am going mad ( possible 
>>> :-) ) or cifs is broken if you do not use winbind.
>>>
>>> I can mount (via a script run at login) the users directory from the 
>>> server provided I do not use 'multiuser' but any files are created 
>>> on the server with the WRONG uid i.e. the user I login with is uid 
>>> 3000017, if the permissions on the client are checked the file 
>>> belongs to the user, but if checked on the server, the files do not 
>>> belong to the user, they belong to a uid '3000000'.
>>> I do not know where this user comes from, getent passwd on the 
>>> server does not show this user, but if I create a testdir on the 
>>> server I can chown it to 3000000.
>>>
>>> If I try to mount the users directory using multiuser, the mount 
>>> fails because it now requires roots/Administrators krb5_cc and I 
>>> have not created it.
>>>
>>> I am now coming round to the idea that if the samba team want S4 to 
>>> be used with unix clients then some work needs to be done to ensure 
>>> it easily works as expected and in my opinion the first thing that 
>>> needs to happen is the S3 winbind that exists at present needs to be 
>>> thrown into the wastebin.
>>>
>>> Rowland
>> Hi Rowland
>> It WAS an idmap/winbind problem. On the one hand we can get our 
>> uid:gid from idmap.ldb or we can get it from AD. But not a mix of the 
>> two. What I had was the server using idmap and the client using AD. 
>> Disaster! The line:
>> idmap_ldb:use rfc2307 = Yes
>> needs to be added to smb.conf for uid:gid ALWAYS being pulled from 
>> AD. Just to be sure, I also had a long ldbedit session on idmap.ldb 
>> to remove the users that Samba added before I got the syntax right 
>> for the smb.conf line above.
>>
>> I agree that winbind is too complicated a way to go about adding 
>> Linux clients to AD, especially when there are point and click 
>> methods around (I believe you just found one: we use nss-ldapd). But 
>> what really seems to confuse the issue is that we have TWO methods 
>> for ID mapping. idmap or the AD ldap. I'd vote for going with just 
>> one method: AD. Having choice in matters such as these can only add 
>> to the already confusing winbind/AD setup, as I have just so 
>> painfully found out:(
>>
>> I believe the devs think that as time goes by, Samba4 will get more 
>> attention from companies wanting to deploy more and more windows 
>> boxes. Where I come from, we're going the other way: even though 
>> we'll always cater for a few microsoft programs, the windows boxes 
>> are slowly but surely being replaced by Linux. Maybe in a year or so, 
>> none of this will be relevant as we go cloud. Not sure. Having said 
>> all this, I still think S4 is a remarkable achievement.
>> Cheers,
>> Steve
>>
> Hi Steve
> That may have been your problem, but it wasn't mine :-(
>
> I had that line in smb.conf, but the users directory was mounted on 
> the client and the files etc belonged the correct user whose uidNumber 
> was 3000017 but all newly created files became the property of 
> 3000000, both on the client & the server. I could not find the user 
> 3000000 anywhere, so I went and read your postings over on the cifs 
> mailing list to see if it gave me any ideas, it did :-) .
>
> I found the problem & user 3000000 in /usr/local/samba/private/idmap.ldb
>
> # record 24
> dn: CN=S-1-5-32-544
> cn: S-1-5-32-544
> objectClass: sidMap
> objectSid: S-1-5-32-544
> type: ID_TYPE_BOTH
> xidNumber: 3000000
> distinguishedName: CN=S-1-5-32-544
>
> A bit more googling produced this:
>
> SID: S-1-5-32-544
> Name: Administrators
> Description: A built-in group. After the initial installation of the 
> operating system, the only member of the group is the Administrator 
> account. When a computer joins a domain, the Domain Admins group is 
> added to the Administrators group. When a server becomes a domain 
> controller, the Enterprise Admins group also is added to the 
> Administrators group.
>
> I had added my user to the Domain Admins group, so, using samba-tool, 
> I removed him again, chown all the users files etc on the server to 
> the user and rebooted the client.
>
> YEAH it works!!!!
>
> OK, how did my users uidNumber become the same (but seemingly only 
> when saving files on a cifs mount) as a group number by just joining 
> the group via samba-tool?
>
> Rowland
>
>
Hi Rowland
Good to hear you got it going. Yeah, it's BUILTIN\Administrators here 
too. I think it is everywhere, like the rid 500 for Domain Admin.

wbinfo --uid-to-sid=3000000
S-1-5-32-544

wbinfo --sid-to-name=S-1-5-32-544
BUILTIN\Administrators 4

I still think you'll need the cifs multiuser option, otherwise all files 
created in the mount will _always_ be owned by the user who made the 
mount in the first place. You'd need pretty open permissions for 
everyone to work and edit files within the share if only one user is to 
own all the files. Maybe that's OK for you but we have to have files 
editable only by their owner, and that owner can be any user who has 
access to the share. In our case, the unix home folders. IOW, where you 
are just after you log in.

Cheers,
Steve