Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 12
I upgraded my client workstation from '3.2.0-4-amd64' to '3.13-1-amd64' and NFS4 took suddenly long time to mount. Client syslog gives: ------------------ zkab kernel: [ 504.213394] RPC: AUTH_GSS upcall timed out. ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jul 2007
    Posts
    54

    NFS4 mount takes long time


    I upgraded my client workstation from '3.2.0-4-amd64' to '3.13-1-amd64' and NFS4 took suddenly long time to mount.

    Client syslog gives:
    ------------------
    zkab kernel: [ 504.213394] RPC: AUTH_GSS upcall timed out.
    zkab kernel: [ 504.213394] Please check user daemon is running.
    ------------------

    On the server I have:
    cat /etc/exports
    /mnt/x-file_1/ 192.168.0.4(rw,subtree_check,sync,fsid=0)

    Both client/server has following:

    cat /etc/default/nfs-common
    NEED_STATD=
    STATDOPTS=
    NEED_IDMAPD=yes
    NEED_GSSD=

    The client mounts NFS4 with autofs.
    Why this delay in NFS4 mount ... had it not in '3.2.0-4-amd64'

  2. #2
    Linux Newbie
    Join Date
    Sep 2007
    Posts
    218
    The 3.2.0-4-amd64 kernel is from Debian's Stable (Wheezy) repo. The 3.13-1-amd64 kernel is currently in both the Testing (Jessie) and the Unstable (Sid) repos. The Testing and Unstable repos occasionally have the same kernel version but not always, and not for long.

    I assume you've been running a Stable system... yes?
    Is the 3.2.0-4-amd64 kernel still installed or was it deleted?
    If the 3.2.0-4-amd64 kernel was deleted, were its config files purged?
    Was there a specific reason for upgrading the kernel?

  3. #3
    Just Joined!
    Join Date
    Jul 2007
    Posts
    54
    Well - I was running Stable before upgrading to 3.13-1-amd64 ... now I run 3.13-1-amd64
    3.2.0-4-amd64 is still installed
    The reason for upgrading was to get the latest software

    After I posted my problem I saw a link (unfortunately in German) NFS4: RPC: AUTH_GSS upcall timed out. - linuxforen.de -- User helfen Usern
    It says that on the client side in /etc/default/nfs-common one should set NEED_GSSD=yes ... but not on the server.
    I did that and restarted nfs-common and it seems to work ... but after reboot syslog gave an error:

    zkab rpc.gssd[2608]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host xxx
    zkab rpc.gssd[2608]: ERROR: No credentials found for connection to server xxx

    Don't get this - I have not installed Kerberos but still get this message.
    Is it installed by default ... if so what should be uninstalled.
    How can I fix this problem ... have no experience with Kerberos auth ?

  4. #4
    Linux Newbie
    Join Date
    Sep 2007
    Posts
    218
    The reason for upgrading was to get the latest software
    Good reason but... the Stable system you're running was built and tested using the Stable kernel. It's now a mixed system using a Testing/Unstable kernel version with (I assume) the Stable versions of nfs-common, libk5crypto3 and other software... which could be why rpc.gssd is looking for a keytab entry that doesn't exist.

    Don't get this - I have not installed Kerberos but still get this message.
    GSS and Kerberos is an overview which Debian's package info also mentions but with less detail.

    As you've got both kernels, have you booted to the Stable kernel to see if the problem resolves itself? If not, have you deleted and purged the Testing/Unstable kernel to see if that resolves it? Can't suggest a fix as I'm not familiar. However, searching 'debian Kerberized NFS without keytab' might give you some answers. Perhaps others here may have some thoughts as well. Good luck.

  5. #5
    Just Joined!
    Join Date
    Jul 2007
    Posts
    54
    Quote Originally Posted by fanderal View Post
    It's now a mixed system using a Testing/Unstable kernel version with (I assume) the Stable versions of nfs-common, libk5crypto3 and other software... which could be why rpc.gssd is looking for a keytab entry that doesn't exist.
    I have booted with 3.13 and have Jessie in /etc/apt/sources.list ... so how can I get a mix of Testing/Unstable/Stable software as I said ...

    Have also for the client:
    /etc/default/nfs-common
    NEED_GSSD=no

    but still syslog tells me ...

    rpc.gssd[10917]: ERROR: No credentials found for connection to server xxx
    rpc.gssd[10917]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host xxx

    Am I the only person who have this problem with NFS ?

  6. #6
    Linux Newbie
    Join Date
    Sep 2007
    Posts
    218
    Re-read my posts and looks like I wasn't clear. Running a mixed system is a bad idea. Debian's Stable branch is known for its stability, which is why it's a good choice for a server. You lose that stability by mixing packages from other branches, and usually leads to the kind of problem you have.

    Comes down to a choice of what's more important to you... the latest software or a stable system.

    Am I the only person who have this problem with NFS ?
    The search phrase in my previous post returned 680 pages on StartPage and 64,900 pages on Google.

  7. #7
    Just Joined!
    Join Date
    Jul 2007
    Posts
    54
    OK - I misunderstood.
    The server runs Stable and my client runs Testing ... of course.

    It feels good to know that I am not the only person on the planet with this problem ... I will dig more deeply into those 64,900 pages on Google

  8. #8
    Linux Engineer
    Join Date
    Apr 2012
    Location
    Virginia, USA
    Posts
    896
    This seems to be a bug: https://bugs.launchpad.net/ubuntu/+s...s/+bug/1270445
    Check that link for a possible work around.

    Your machines are obviously not on a Kerberos realm, therefor setting "NEED_GSSD=YES" will force NFS to try to use the General Security Services Daemon to negotiate Kerberos authentication. /etc/krb5.keytab is the default location for stored Kerberos keys; you don't have any, so therefor you don't have a useable entry in that file.

    In your case, NEED_GSSD should be =NO

  9. #9
    Just Joined!
    Join Date
    Jul 2007
    Posts
    54
    I changes to no:

    # Do you want to start the gssd daemon? It is required for Kerberos mounts.
    NEED_GSSD=no

    and restarted 'nfs-common' and 'autofs'

    raivo@zkab ~ $ sudo service nfs-common restart
    [ ok ] Stopping NFS common utilities: idmapd statd.
    [ ok ] Starting NFS common utilities: statd idmapd.
    raivo@zkab ~ $ sudo service autofs restart
    [ ok ] Stopping automount....
    [ ok ] Starting automount....

    but still error message in syslog ...

  10. #10
    Linux Engineer
    Join Date
    Apr 2012
    Location
    Virginia, USA
    Posts
    896
    Did you read the link I posted for the work around?

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •