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

** Edit: ** I am not using Sabayon Linux anymore and this problem didn't occur on other distributions. I suggest to close this question.

Update: I realized that because of bad hosts file, both machines resolves their local names to 127.0.0.1 instead of their LAN IP Address. Once I changed it and tried to mount, the client shows:

mount.nfs4: timeout set for Sun Mar 31 10:33:38 2013
mount.nfs4: trying text-based options 'sec=krb5,addr=192.168.10.200,clientaddr=192.168.10.103'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting shakuras.darwinia.lan:/

Looking at the client's syslog:

rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.idmapd[13036]: New client: 1a
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa321f0 data 0x7fffcfa320c0
rpc.gssd[13067]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt1a)
rpc.gssd[13067]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 '
rpc.gssd[13067]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt1a)
rpc.gssd[13067]: process_krb5_upcall: service is '*'
rpc.idmapd[13036]: Opened /var/lib/nfs/rpc_pipefs//nfs/clnt1a/idmap
rpc.gssd[13067]: Full hostname for 'server.domain' is 'server.domain'
rpc.gssd[13067]: Full hostname for 'client.domain' is 'client.domain'
rpc.gssd[13067]: No key table entry found for CLIENT$@REALM while getting keytab entry for 'CLIENT$@REALM'
rpc.gssd[13067]: No key table entry found for root/client.domain@REALM while getting keytab entry for 'root/client.domain@REALM'
rpc.gssd[13067]: Success getting keytab entry for 'nfs/client.domain@REALM'
rpc.gssd[13067]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364748098
rpc.gssd[13067]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364748098
rpc.gssd[13067]: using FILE:/tmp/krb5cc_machine_REALM as credentials cache for machine creds
rpc.gssd[13067]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_REALM
rpc.gssd[13067]: creating context using fsuid 0 (save_uid 0)
rpc.gssd[13067]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No Kerberos credentials available
rpc.gssd[13067]: WARNING: Failed while limiting krb5 encryption types for user with uid 0
rpc.gssd[13067]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_REALM for server server.domain
rpc.gssd[13067]: WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server server.domain
rpc.gssd[13067]: Full hostname for 'server.domain' is 'server.domain'
rpc.gssd[13067]: Full hostname for 'client.domain' is 'client.domain'
rpc.gssd[13067]: No key table entry found for CLIENT$@REALM while getting keytab entry for 'CLIENT$@REALM'
rpc.gssd[13067]: No key table entry found for root/client.domain@REALM while getting keytab entry for 'root/client.domain@REALM'
rpc.gssd[13067]: Success getting keytab entry for 'nfs/client.domain@REALM'
rpc.gssd[13067]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364748098
rpc.gssd[13067]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364748098
rpc.gssd[13067]: using FILE:/tmp/krb5cc_machine_REALM as credentials cache for machine creds
rpc.gssd[13067]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_REALM
rpc.gssd[13067]: creating context using fsuid 0 (save_uid 0)
rpc.gssd[13067]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No Kerberos credentials available
rpc.gssd[13067]: WARNING: Failed while limiting krb5 encryption types for user with uid 0
rpc.gssd[13067]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_REALM for server server.domain
rpc.gssd[13067]: WARNING: Failed to create machine krb5 context with any credentials cache for server server.domain
rpc.gssd[13067]: doing error downcall
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt1a
rpc.idmapd[13036]: Stale client: 1a
rpc.idmapd[13036]:  -> closed /var/lib/nfs/rpc_pipefs//nfs/clnt1a/idmap

The server's syslog only shows:

krb5kdc[31142]: AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.10.103: NEEDED_PREAUTH: nfs/client.domain@REALM for krbtgt/REALM@REALM, Additional pre-authentication required

Client ktutil:

ktutil 
ktutil:  rkt /etc/krb5.keytab 
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3   nfs/client.domain@REALM

Server ktutil:

ktutil:  rkt /etc/krb5.keytab 
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2   nfs/server.domain@REALM

Previous Post:

I'm trying to setup a secure NFS4 server using Kerberos. My network has a local DNS server. Both the client and the server can (reverse) lookup each other. At first, I followed this tutorial:

http://wiki.paraf.in/~parafin/linux/nfs4krb5

Since I'm using Sabayon Linux, which is gentoo based. I then realized that the syntax for the NFS exported file might be incorrect. Currently, when NFS exports is set up like this:

/export gss/krb5p(rw,insecure,async,no_root_squash,no_subtree_check)

The client can mount the remote filesystem. However, trying to change it to Kerberos:

/export gss/krb5(rw,insecure,async,no_root_squash,no_subtree_check)

And the client cannot mount the filesystem anymore. The mount command:

mount -o sec=krb5 -t nfs4  server.domain:/export /mnt/nfs/ -vvv

seems to hang forever. After a couple of minutes I can see the client's dmesg:

nfs: server server.domain not responding, timed out

The command stills hangs, though. Some additional facts:

  1. The KDC and the NFS server are the same machine
  2. idmap, rpc.svcgssd and nfs runs on the server
  3. idmap, rpc.gssd and nfs runs on the client
  4. The kernel has support for gss rpc
  5. Keytab files for both client and the server are placed in /etc/krb5.keytab, readable only by root

Trying to increase verbosity on both sides, when I connect I can see: Server:

rpc.svcgssd[23856]: sname = nfs/client.domain@REALM
rpc.svcgssd[23856]: DEBUG: serialize_krb5_ctx: lucid version!
rpc.svcgssd[23856]: prepare_krb5_rfc4121_buffer: protocol 1
rpc.svcgssd[23856]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
rpc.svcgssd[23856]: doing downcall
rpc.svcgssd[23856]: mech: krb5, hndl len: 4, ctx len 52, timeout: 1364700223 (33977 from now), clnt: nfs@client.domain, uid: -1, gid: -1, num aux grps: 0:
rpc.svcgssd[23856]: sending null reply
rpc.svcgssd[23856]: writing message: [BINARY MESSAGE]
rpc.svcgssd[23856]: finished handling null request
rpc.svcgssd[23856]: entering poll

Client:

rpc.gssd[20295]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt64)
rpc.gssd[20295]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 '
rpc.gssd[20295]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt64)
rpc.gssd[20295]: process_krb5_upcall: service is '*'
rpc.gssd[20295]: Full hostname for 'server.domain' is 'server.domain'
rpc.gssd[20295]: Full hostname for 'localhost' is 'localhost'
rpc.gssd[20295]: No key table entry found for CLIENT$@REALM while getting keytab entry for 'CLIENT$@REALM'
rpc.gssd[20295]: No key table entry found for root/localhost@REALM while getting keytab entry for 'root/localhost@REALM'
rpc.gssd[20295]: No key table entry found for nfs/localhost@REALM while getting keytab entry for 'nfs/localhost@REALM'
rpc.gssd[20295]: No key table entry found for host/localhost@REALM while getting keytab entry for 'host/localhost@REALM'
rpc.gssd[20295]: Success getting keytab entry for nfs/*@REALM
rpc.gssd[20295]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364700223
rpc.gssd[20295]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364700223
rpc.gssd[20295]: using FILE:/tmp/krb5cc_machine_REALM as credentials cache for machine creds
rpc.gssd[20295]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_REALM
rpc.gssd[20295]: creating context using fsuid 0 (save_uid 0)
rpc.gssd[20295]: creating tcp client for server server.domain
rpc.gssd[20295]: DEBUG: port already set to 2049
rpc.gssd[20295]: creating context with server nfs@server.domain
rpc.gssd[20295]: DEBUG: serialize_krb5_ctx: lucid version!
rpc.gssd[20295]: prepare_krb5_rfc4121_buffer: protocol 1
rpc.gssd[20295]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
rpc.gssd[20295]: doing downcall

I'm not sure why does it try to get a key for CLIENT$@REALM (Where's the dollar sign at the end of the client name coming from?)

share|improve this question

closed as unclear what you're asking by Michael Hampton Dec 17 '13 at 10:15

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

    
check that times are in sync on the client and server –  tigran Mar 31 '13 at 7:58
1  
this is wrong - host/localhost@. It should use names used in ktab files. –  tigran Mar 31 '13 at 7:59
    
Time is synced on both server and the client. –  reish Mar 31 '13 at 9:37
    
check that host names do not point to 127.0.0.1 in /etc/hosts. Could you provide the keytab entries list? –  tigran Mar 31 '13 at 11:17
    
@tigran - The hosts resolved to 127.0.0.1 at first, which was my first problem causing the mount to hang. When I fixed that I started to experiment the second problem - permission denied issues. I attached the keytab entries list to the post. –  reish Mar 31 '13 at 11:29

Browse other questions tagged or ask your own question.