On 10/19/2014 10:25 PM, steve wrote:
>
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.
The local Windows admins are closing SMB1 because they consider it too
insecure. On Windows Server 2012, SMB1 is allegedly deprecated already.
So I would very much like to use SMB3 to get to the Windows file
servers. Kerberized SMB1 worked like a charm. Speed/bandwidth is not
really the issue here.
Best'
Jurjen
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
