Re: Kerberized mount.cifs with SMB>1?

[steve <steve-dZ4O0aZtNmBWk0Htik3J/w@public.gmane.org>]

 >
On 19/10/14 21:58, Jurjen Bokma wrote:
> On 08/20/2014 07:16 PM, Jurjen Bokma wrote:
>> On 08/20/2014 04:43 PM, steve wrote:
>>> On Wed, 2014-08-20 at 16:08 +0200, Jurjen Bokma wrote:
> <snip>
>>> The upcall has nothing to go on. Get it working with cifs first:
>>>
>>> Who mounts the share? Add a domain user with a uid:gid key to the keytab
>>> and:
> <snip>
>>> mount.cifs //your/share /mnt -ousername=cifsuser,sec=krb5
>> This works, as it uses SMB1. SMB1 also works *with* all the frills. But
>> it fails with 2.0, 2.1 or 3.0:
>>
>> mount.cifs //your/share /mnt -ousername=cifsuser,sec=krb5,vers=3.0
> <snip>
>
> No matter whether I use my own Samba server or a Windows (2012) server,
> vers=2.0 or vers=3.0 fails with "permission denied", while 'vers=1.0'
> works perfectly:
>
> mount.cifs //server.mydom.com/cnc  /mnt/cnc
> -overs=1.0,sec=krb5,username=cifsuser,cruid=1234567,domain=MYDOM.COM
>
> With SMB>1, no Kerberos traffic in Wireshark. If it is encapsulated,
> that would explain a part. But the ticket still would have to be granted
> by the Kerberos server, and I don't see that either. Also, request-key
> is not being called with SMB>1. So I must conclude that Steve is right:
> the upcall has nothing to go on. But how to tell it?
>
> Any hints as to why this fails with SMB>1 would be much appreciated.
>
> Best Regards

Not sure why you would want smb2 with Linux boxes. Does it improve 
performance? Loading a big jpg to gimp to a lxde client still beats a w7 
client on the same hardware.
Cheers,