samba - Apr 2013 - Samba4 Does cifs need a keytab for the multiuser option?

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

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




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.