Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to mount a cifs folder on a ubuntu server with multiuser support from a windows DC.

I can get user kerberos tickets as root on the server and mount the directory with kerberos without any problems. But I don't want to mount the directory as a user, it should be mounted as multiuser and accessible for all users on the server.

Maybe this is just a general question about understanding, maybe you can correct me whats wrong here.

  • The multiuser mounting server needs a keytab from the DC (ktpass export for cifs/samba.domain)
  • Samba uses this keytab to mount the DC share multiuser
  • Winbind / kerberos authenticates the users against the DC and issues a ticket
  • The user can access the share with his ticket

I exported a keytab file on the DC and put it as the global keytab file /etc/krb5.keytab

root@remote:/etc# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 cifs/remote.mbeya.domain@MBEYA.domain (des-cbc-md5) 

But I still cannot mount the directory because the key is not available mount error(126): Required key not available

syslog shows me this:

May 17 11:37:22 remote cifs.upcall: key description: cifs.spnego;0;0;3f000000;ver=0x2;host=nina.mbeya.domain.org;ip4=10.10.10.17;sec=krb5;uid=0x0;creduid=0x0;user=root;pid=0x599b
May 17 11:37:22 remote cifs.upcall: ver=2
May 17 11:37:22 remote cifs.upcall: host=nina.mbeya.domain.org
May 17 11:37:22 remote cifs.upcall: ip=10.10.10.17
May 17 11:37:22 remote cifs.upcall: sec=1
May 17 11:37:22 remote cifs.upcall: uid=0
May 17 11:37:22 remote cifs.upcall: creduid=0
May 17 11:37:22 remote cifs.upcall: user=root
May 17 11:37:22 remote cifs.upcall: pid=22939
May 17 11:37:22 remote cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_1000
May 17 11:37:22 remote cifs.upcall: find_krb5_cc: /tmp/krb5cc_1000 is owned by 1000, not 0
May 17 11:37:22 remote cifs.upcall: krb5_get_init_creds_keytab: -1765328378
May 17 11:37:22 remote cifs.upcall: handle_krb5_mech: getting service ticket for cifs/nina.mbeya.domain.org
May 17 11:37:22 remote cifs.upcall: cifs_krb5_get_req: unable to resolve (null) to ccache
May 17 11:37:22 remote cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328245)
May 17 11:37:22 remote cifs.upcall: handle_krb5_mech: getting service ticket for host/nina.mbeya.domain.org
May 17 11:37:22 remote cifs.upcall: cifs_krb5_get_req: unable to resolve (null) to ccache
May 17 11:37:22 remote cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328245)

I appreciate any input on this.

Thanks

share|improve this question

1 Answer 1

You noted that you can get "user Kerberos tickets as root" but you have a "key is not available" error.

find_krb5_cc: /tmp/krb5cc_1000 is owned by 1000, not 0

This error means mount.cifs does not have access to the Kerberos ticket because is not owned by root (userid: 0), which calls mount.cifs. I would assume that the Kerberos tickets root obtained with a user's password were designated for use only by that user.

Now why does mount want the ticket to be owned by root? This part of first line:

uid=0x0;creduid=0x0;user=root;

may be the reason. Mount.cifs is being carried out as root. You might want to try changing uid and creduid to the useruid of the user.

I don't know where you're calling mount.cifs from, so I'm sorry if that's a little vague. Could you please give the mount.cifs command you're running and its options?

As for the share being "accessible for all users on the server": I have pam_mount run after a user logs in and mount a share with their username, password and their Kerberos ticket, so I'm not using a keytab. This is the mount command I'm calling:

mount -t cifs //<SERVER>/<VOLUME> <MOUNTPOINT> -o username=%(USER),sec=krb5,domain=<DOMAIN>,cruid=%(USERUID),uid=%(USERUID),gid=%(USERGID),rw

Add the authorized users to a single group. Also set file_mode= and dir_mode= to the correct permissions for the group to have read/write access to the file, something like 770.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.