samba/kerberos/nfs woes

[Afasoas]

Setting up my own Linux is proving to be a baptism of fire.

Thus far, I have Samba working as a primary domain controller and I've joined a Win7 machine to it. I can access and edit files on the Samba shares.
In installed Samba with Kerberos.

Now, I've setup NFS (with RPCBIND) and I've configured my zpools/filesystems with the sharenfs property.

Code: [Select]

daniel@colnago ~ $ showmount -e brox
Export list for brox:
/mnt/bikeshed/sarah   172.168.1.0/24,172.168.2.0/24
/mnt/bikeshed/daniel  172.168.1.0/24,172.168.2.0/24
/mnt/bikeshed/backupz 172.168.1.0/24,172.168.2.0/24
/mnt/bikeshed         192.168.0.0/16
/mnt/usb/TouroHDD     172.16.0.0/16
/mnt/bikeshed/svn     192.168.0.0/16
/mnt/biz              172.168.1.0/24,172.168.2.0/24
/mnt/biz/dcp          172.168.1.0/24,172.168.2.0/24
/mnt/biz/it           172.168.1.0/24,172.168.2.0/24
/mnt/media/movies     172.168.1.0/24,172.168.2.0/24
/mnt/media/music      172.168.1.0/24,172.168.2.0/24

However, when I try and mount my NFS shares I get:

Code: [Select]

mount.nfs: access denied by server while mounting brox:/mnt/biz/dcp
mount.nfs: access denied by server while mounting brox:/mnt/biz/it
mount.nfs: access denied by server while mounting brox:/mnt/bikshed/daniel
mount.nfs: access denied by server while mounting brox:/mnt/media/movies
mount.nfs: access denied by server while mounting brox:/mnt/media/music

And from my syslog:

Code: [Select]

Oct 25 16:03:02 colnago kernel: [  335.303465] RPC: AUTH_GSS upcall timed out.
Oct 25 16:03:02 colnago kernel: [  335.303465] Please check user daemon is running.
Oct 25 16:03:32 colnago kernel: [  364.785060] RPC: AUTH_GSS upcall timed out.
Oct 25 16:03:32 colnago kernel: [  364.785060] Please check user daemon is running.
Oct 25 16:03:48 colnago kernel: [  380.844492] RPC: AUTH_GSS upcall timed out.
Oct 25 16:03:48 colnago kernel: [  380.844492] Please check user daemon is running.
Oct 25 16:04:04 colnago kernel: [  396.907917] RPC: AUTH_GSS upcall timed out.
Oct 25 16:04:04 colnago kernel: [  396.907917] Please check user daemon is running.
Oct 25 16:04:20 colnago kernel: [  412.975335] RPC: AUTH_GSS upcall timed out.
Oct 25 16:04:20 colnago kernel: [  412.975335] Please check user daemon is running.

This appears to be related to this bug:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1270445

I tweaked by nfs-common configuration to use gssd, and whilst that stops the timeouts but I get

Code: [Select]

Oct 25 15:11:25 colnago rpc.gssd[1280]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host brox.bikeshed.internal

Which I think is reasonable, but I haven't configured NFS to use Kerberos.
I'll try configuring NFS to use Kerberos and if that doesn't work, I can try black listing the the 'rpcsec_gss_krb5' kernel module - if I can confirm that it won't break Samba. I know it is used for NFS and Kerberos but I'm not sure whether it is needed for Samba? I suspect not as Samba doesn't use rpcbind?

Anyway, that brings me to my unrelated final question. I've used rpcbind with NFS to prevent DHCP clients from accessing the NFS shares, and that's great because we do often have guests staying. As far as I can tell, rpcbind and xinetd are fairly similar and I can use xinetd with Samba. What's the benefit of doing so? Will installing and configuring xinetd affect the use of rpcbind?

I'm sure I will get it resolved (I've got this far!) but if any more learned geeks have any insight, that'd be appreciated.
I also realise I'm going OTT in some respects for a home set-up, but the learning curve is useful in the day job.

Thanks

[hazeii]

xinetd and rcpbind are different animals - xinetd starts network services on demand (i.e. it listens for an incoming connection, and runs a program when there is one) while rpcbind is kind of a meeting board for programs. So normally you'd have rpcbind and samba running all the time (and therefore not started via xinetd).

Here I run NFS on the home server (for linux clients) and samba (for windows clients); no Kerberos though.

[Afasoas]

I have the NFS shares sorted. The allowed IP addresses on my NFS exports were incorrect.. 172.168 rather than 172.16.
Fairly obvious!

Since I've been investigating this, I've learned I can secure NFS quite easily with Kerberos so I'm just in the throws of doing that.

Then all I've got a nasty error appearing in my syslog to resolve. Nearly there!