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

[steve]

On 11/04/13 20:39, Rowland Penny wrote:
> On 11/04/13 17:27, steve wrote:
>> Hi
>> samba --version
>> Version 4.0.6-GIT-4bebda4
>>
>> smb.conf:
>> [users]
>> path = /home/users
>> read only = No
>>
>> Working on the DC which is also the fileserver
>> user steve2 can write to his folder at /home/users/steve2
>>
>> But if we now mount the share:
>> sudo mount -t cifs //doloresdc/users /mnt -osec=krb5,multiuser
>>
>> he can't write to the mounted share at /mnt/users/steve2 He gets 
>> 'Permission denied'. His id is the same, all that's changed is that 
>> now it's mounted via cifs.
>>
>> The mount:
>>
>> Apr 11 18:18:16 doloresdc cifs.upcall: key description: 
>> cifs.spnego;0;0;3f000000;ver=0x2;host=doloresdc;ip4=192.168.1.100;sec=krb5;uid=0x0;creduid=0x0;user=root;pid=0x116b
>> Apr 11 18:18:16 doloresdc cifs.upcall: ver=2
>> Apr 11 18:18:16 doloresdc cifs.upcall: host=doloresdc
>> Apr 11 18:18:16 doloresdc cifs.upcall: ip=192.168.1.100
>> Apr 11 18:18:16 doloresdc cifs.upcall: sec=1
>> Apr 11 18:18:16 doloresdc cifs.upcall: uid=0
>> Apr 11 18:18:16 doloresdc cifs.upcall: creduid=0
>> Apr 11 18:18:16 doloresdc cifs.upcall: user=root
>> Apr 11 18:18:16 doloresdc cifs.upcall: pid=4459
>> Apr 11 18:18:16 doloresdc cifs.upcall: find_krb5_cc: considering 
>> /tmp/krb5cc_0
>> Apr 11 18:18:16 doloresdc cifs.upcall: find_krb5_cc: 
>> FILE:/tmp/krb5cc_0 is valid ccache
>> Apr 11 18:18:16 doloresdc cifs.upcall: handle_krb5_mech: getting 
>> service ticket for doloresdc
>> Apr 11 18:18:16 doloresdc cifs.upcall: handle_krb5_mech: obtained 
>> service ticket
>>
>> user steve2, (uid=3000032) goes to his cifs mounted share:
>>
>> Apr 11 18:19:50 doloresdc cifs.upcall: key description: 
>> cifs.spnego;3000032;20513;3f000000;ver=0x2;host=doloresdc;ip4=192.168.1.100;sec=krb5;uid=0x2dc6e0;creduid=0x2dc6e0;pid=0x1193
>> Apr 11 18:19:50 doloresdc cifs.upcall: ver=2
>> Apr 11 18:19:50 doloresdc cifs.upcall: host=doloresdc
>> Apr 11 18:19:50 doloresdc cifs.upcall: ip=192.168.1.100
>> Apr 11 18:19:50 doloresdc cifs.upcall: sec=1
>> Apr 11 18:19:50 doloresdc cifs.upcall: uid=3000032
>> Apr 11 18:19:50 doloresdc cifs.upcall: creduid=3000032
>> Apr 11 18:19:50 doloresdc cifs.upcall: pid=4499
>> Apr 11 18:19:50 doloresdc cifs.upcall: find_krb5_cc: considering 
>> /tmp/krb5cc_3000032_NI8WDi
>> Apr 11 18:19:50 doloresdc cifs.upcall: find_krb5_cc: 
>> FILE:/tmp/krb5cc_3000032_NI8WDi is valid ccache
>> Apr 11 18:19:50 doloresdc cifs.upcall: find_krb5_cc: considering 
>> /tmp/krb5cc_0
>> Apr 11 18:19:50 doloresdc cifs.upcall: find_krb5_cc: /tmp/krb5cc_0 is 
>> owned by 0, not 3000032
>> Apr 11 18:19:50 doloresdc cifs.upcall: handle_krb5_mech: getting 
>> service ticket for doloresdc
>> Apr 11 18:19:50 doloresdc cifs.upcall: handle_krb5_mech: obtained 
>> service ticket
>>
>> but cannot write to it:(
>>
>> This works OK if I drop the multiuser option but that's no good for 
>> us as we're trying to migrate erm, multiple users from nfs to cifs on 
>> our Linux boxes.
>> Question: Am I missing a keytab? Does cifs need any keys for the 
>> multiuser option?
>>
>> Cheers,
>> Steve
>>
> Hi Steve, in a word YES!
> If you are mounting the users home directory from the S4 server via 
> cifs, I do not think that you need the multiuser option. I think you 
> only need it if you want multiple users to use the the same mount.
>
> Rowland
>
>
>
>
Hi Rowland, hi everyone
I think I do need multiuser because I am mounting the users home 
directories and many users will need to access their own folders with 
their own uid:gid. That can't happen if the mount is owned by just one 
user since all files are created by that uid:gid combination,no good for 
hundreds of different users. In fact we have just that with nfs at the 
mement but want to replace it with cifs because of locking problems 
between nfs and windows.

Anyway, I just put the host and machine clients in /etc/krb5.keytab and 
nada. Still  the same. Permission denied when a user tries to write to 
his cifs mounted home folder.

I think this has something to do with changes in cifs-utils but. . .

Cheers,
Steve