Can't mount samba share with krb/multiuser at bootup in fstab

Bug #1130781 reported by Robstarusa
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ntp (Ubuntu)
New
Low
Unassigned

Bug Description

I have the following setup:

A samba server on Ubuntu 12.04, and a samba client on 12.04

My fstab line looks as follows:
//cifserver.mydomain.com/data /data cifs cache=strict,sec=krb5,multiuser,acl,user=SERVERNAME$ 0 0

The client name is: servername.mydomain.com
The cifs server name is: cifserver.mydomain.com

I'm using windbind with idmap_rid to enumerate uids & gids.

I have joined both servers to the domain and created a krb5.keytab.

After the system has booted, I can login as root via ssh key & run "mount /data" as root (no kerberos tickets) and the share WILL mount & work properly and I'm assigned a kerberos default:principal of servername$mydomain.com , a krbtgt & a cifs/server service ticket. It works. Multiuser permissions work as well (very cool).

If I try to have this work via fstab, it does NOT work with the following cifs.upcall errors:

> cifs.upcall: key description: cifs.spnego;0;0;3f000000;ver=0x2;host=cifserver.mydomain.com;ip4=10.1.5.16;sec=krb5;uid=0x0;creduid=0x0;user=SERVERNAME$;pid=0x2c7
> cifs.upcall: ver=2
> cifs.upcall: host=cifserver.mydomain.com
> cifs.upcall: ip=10.1.5.16
> cifs.upcall: sec=1
> cifs.upcall: uid=0
> cifs.upcall: creduid=0
> cifs.upcall: user=SERVERNAME$
> cifs.upcall: pid=711
> cifs.upcall: krb5_get_init_creds_keytab: -1765328347
> cifs.upcall: handle_krb5_mech: getting service ticket for cifs/cifserver.mydomain.com
> cifs.upcall: cifs_krb5_get_req: unable to resolve (null) to ccache
> cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328245)
> cifs.upcall: handle_krb5_mech: getting service ticket for host/cifserver.mydomain.com
> cifs.upcall: cifs_krb5_get_req: unable to resolve (null) to ccache
> cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328245)

I've reported this to the linux kernel cifs list & it seems that the cifs share is trying to mount prior to the system being ready.

For this reason I've assigned this to upstart. If this should belong to another package, feel free to move it. This is my best guess.

Please see the final response/dermination here:
http://article.gmane.org/gmane.linux.kernel.cifs/7832

You can also see the thread here (sorry I don't know another way to show just this thread on the mailing list)
First post: http://article.gmane.org/gmane.linux.kernel.cifs/7821
second post: http://article.gmane.org/gmane.linux.kernel.cifs/7830
Third post: http://article.gmane.org/gmane.linux.kernel.cifs/7831
Fourth Post: http://article.gmane.org/gmane.linux.kernel.cifs/7832

Thanks for looking into this. If there is a more proper way/place to have auto-mounted cifs mounts with kerberos credentials mounted at startup, please advise. I need this share up at boot even if nobody has logged in so that automated jobs & other services can run.

Revision history for this message
Robstarusa (rob-naseca) wrote :

OS is Ubuntu 12.04.1 LTS
Kernel is 3.5.0-23-generic
Samba-common is 2:3.6.9-1ubuntu1
cifs-utils is 2:5.1-1ubuntu1

Revision history for this message
Steve Langasek (vorlon) wrote :

According to the linked thread, your mount is failing because you have clock skew. Is there something wrong with the clock on your system? the hwclock job should run before mountall starts, and ensure the system clock is set correctly from the hardware's RTC. Since the allowed clock skew for Kerberos is 5 minutes, unless there's something wrong with your hardware clock, there should be no need for the system to set the time from the network first before mounting Samba shares.

affects: upstart (Ubuntu) → mountall (Ubuntu)
Changed in mountall (Ubuntu):
status: New → Incomplete
Revision history for this message
Robstarusa (rob-naseca) wrote :

I'm not sure if it doesn't auto-mount due to clock skew or not, but as SOON as the box is up, if I login and manually mount at as root, then it works fine. I do know once the machine is up & I login, the date/time looks fine as well.

== From the thread ===
"I've tried this but with only partial success. "mount /data" works (see definition of /data below), but not
at startup.

I'm not sure exactly why it's failing at system startup, but if I ssh into my machine as root using ssh keys (no
kerberos tickets) and then do "mount /mountpoint" it works as expected. root user is granted the default
prinicpal: SERVERNAME$ <at> DOMAIN.COM (confirmed with klist). I get a krbtgt ticket & cifs ticket.

Since it works when I try it as root AFTER system startup but not at statup, I'm guessing this is an Ubuntu
issue of some sort (Ubuntu server 12.04). I know at startup I get"
== End From the thread ===

It's hard for me to troubleshoot this now as I was trying this in February & it is now October. This machine has long ago been rebuilt.

Sorry,

Robert

Revision history for this message
Steve Langasek (vorlon) wrote :

> I'm not sure if it doesn't auto-mount due to clock skew or not,

Well, this is exactly the diagnosis given in the message you linked to. So if it's clock skew, it must be a bad system clock, or a bad clock value in your BIOS clock.

> if I login and manually mount at as root, then it works fine.

That's not surprising, if the clock is being set from NTP immediately afterwards. This could happen because the /etc/network/if-up.d/ntpdate script which sets the clock also does this in the background, so if you have a bad system clock and are getting the time from the network, there's a race condition and the clock may not yet be set by the time the attempt is made to mount the share.

> It's hard for me to troubleshoot this now as I was trying this in
> February & it is now October. This machine has long ago been rebuilt.

I take this to mean that you're no longer able to reproduce the problem. The contents of the ntp package do certainly indicate a race condition, so there's a real bug; but without further information about why this was causing problems for you specifically, the theory is that this only happens with a broken BIOS clock, so is a low priority to fix.

affects: mountall (Ubuntu) → ntp (Ubuntu)
Changed in ntp (Ubuntu):
importance: Undecided → Low
status: Incomplete → New
Revision history for this message
steverweber (steve-r-weber) wrote :

close

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.