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
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 ancache d 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
Hi Steve, each user needs to have their own kerberos cache, I seem
to have this working on my small test network but I am using sssd
as I have come to the conclusion that winbind sucks ;-)
Rowland
Hi Rowland
Absolutely agree on winbind;) We've always used nss-ldapd. Each user
who logs in gets his own cache under /tmp e.g. /tmp/krb5cc_3000032
so I don't think it's the cache that's the problem. If we use
kerberised nfs instead of cifs, the user can write to the share fine.
It's something about the cifs multiuser I've missed I'm almost certain.
Cheers,
Steve
Hi
Maybe this has something to do with it?
dmesg
[ 535.106336] FS-Cache: Loaded
[ 535.121753] FS-Cache: Netfs 'cifs' registered for caching
[ 535.121790] Key type cifs.spnego registered
[ 535.121823] Key type cifs.idmap registered
[ 535.589126] CIFS VFS: Send error in SessSetup = -126
[ 535.589270] CIFS VFS: cifs_mount failed w/return code = -126
[ 821.816568] CIFS VFS: Send error in SessSetup = -126
[ 823.964101] CIFS VFS: Send error in SessSetup = -126
[ 835.880675] CIFS VFS: Send error in SessSetup = -126
Thanks, Steve
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
