Your message dated Sat, 14 Sep 2024 10:00:45 +0200 (CEST)
with message-id <20240914080045.096cbbe2...@eldamar.lan>
and subject line Closing this bug (BTS maintenance for src:linux bugs)
has caused the Debian Bug report #616077,
regarding "AUTH_GSS upcall timed out" in export with kerberos
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
616077: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616077
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: nfs-kernel-server
Version: 1.2.2-4
Short description: kerberized nfs4 exports do work, but nevertheless
there are continuous kernel messages: "RPC: AUTH_GSS upcall timed
out."
Procedure to trigger the bug:
1. On the server machine, /etc/init.d/nfs-common and
/etc/init.d/nfs-kernel-server have already been run with argument
start.
2. On the client machine, the nfs-exported directories are not yet
mounted and /etc/init.d/nfs-common has been called with argument stop.
3. On the client machine, call /etc/init.d/nfs-common with argument
start.
4. On the client machine, mount nfs-exported directories.
As yet, nothing wrong happens.
5. From the server machine, log into the client machine with ssh as a
non-root user, thus forwarding kerberos credentials to the client
machine: the nfs-exported directories are normally accessible on the
client machine (according to the rights of this user).
After this, the kernel on the server machine logs this to
/var/log/messages every 30 seconds (too much output for the log
file!):
Mar 2 09:44:27 olaf kernel: [60989.928631] RPC: AUTH_GSS upcall timed out.
Mar 2 09:44:27 olaf kernel: [60989.928632] Please check user daemon is running.
But /usr/sbin/rpc.svcgssd is still running on the server, and the user
can still access the nfs-exported directories on the client.
Note that the kernel messages every 30 seconds continue even after
user logout from the client, unmounting all nfs-exported directories
on the client, stopping /etc/init.d/nfs-common on the client, and
stopping /etc/init.d/nfs-kernel-server and /etc/init.d/nfs-common on
the server. Stopping /etc/init.d/nfs-kernel-server and
/etc/init.d/nfs-common and starting it again (in opposite order) gives
these kernel messages:
Mar 2 09:49:15 olaf kernel: [61278.055487] svc: failed to register lockdv1 RPC
service (errno 97).
Mar 2 09:49:15 olaf kernel: [61278.056254] NFSD: Using /var/lib/nfs/v4recovery
as the NFSv4 state recovery directory
Mar 2 09:49:15 olaf kernel: [61278.056268] NFSD: starting 90-second grace
period
(but these messages are there in each nfs-kernel-server start), and
then the above AUTH_GSS messages every 30 seconds continue. Only a
server reboot helps. (With a newer kernel on the server ---
linux-image-2.6.37-1-amd64 of sid, the messages do not seem to
continue, but are also present in the first place).
After downgrading nfs-common and nfs-kernel-server to the lenny
versions (1.1.2-6), this bug does not occur.
I would test nfs-utils-1.2.3 if it were available as debian packages
in sid, but hesitate to mess around and install it from source.
Other configuration:
- Debian squeeze amd64 system, linux-image-2.6.32-5-amd64 both on
server and client machine.
- /etc/exports on server:
/export gss/krb5p(rw,sync,fsid=0,no_subtree_check)
/export/nfs gss/krb5p(rw,sync,nohide,no_subtree_check)
/export/home gss/krb5p(rw,sync,nohide,no_subtree_check)
/export/mail gss/krb5p(rw,sync,nohide,no_subtree_check)
- /etc/fstab on client:
...
server.machine:/nfs /usr/nfs nfs4 sec=krb5p 0 0
server.machine:/home /home nfs4 sec=krb5p 0 0
server.machine:/mail /var/mail nfs4 sec=krb5p 0 0
- /etc/default/nfs-common on server:
# If you do not set values for the NEED_ options, they will be attempted
# autodetected; this should be sufficient for most people. Valid alternatives
# for the NEED_ options are "yes" and "no".
# Do you want to start the statd daemon? It is not needed for NFSv4.
NEED_STATD=
# Options for rpc.statd.
# Should rpc.statd listen on a specific port? This is especially useful
# when you have a port-based firewall. To use a fixed port, set this
# this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
# For more information, see rpc.statd(8) or
http://wiki.debian.org/?SecuringNFS
STATDOPTS=
# Do you want to start the idmapd daemon? It is only needed for NFSv4.
NEED_IDMAPD=
# Do you want to start the gssd daemon? It is required for Kerberos mounts.
NEED_GSSD=
- /etc/default/nfs-kernel-server on server:
# Number of servers to start up
RPCNFSDCOUNT=8
# Runtime priority of server (see nice(1))
RPCNFSDPRIORITY=0
# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information,
# see rpc.mountd(8) or http://wiki.debian.org/?SecuringNFS
RPCMOUNTDOPTS=--manage-gids
# Do you want to start the svcgssd daemon? It is only required for Kerberos
# exports. Valid alternatives are "yes" and "no"; the default is "no".
NEED_SVCGSSD=yes
# Options for rpc.svcgssd.
RPCSVCGSSDOPTS=
- on server, statd idmapd nfsd svcgssd mountd are started
- /etc/default/nfs-common on client:
# If you do not set values for the NEED_ options, they will be attempted
# autodetected; this should be sufficient for most people. Valid alternatives
# for the NEED_ options are "yes" and "no".
# Do you want to start the statd daemon? It is not needed for NFSv4.
NEED_STATD=
# Options for rpc.statd.
# Should rpc.statd listen on a specific port? This is especially useful
# when you have a port-based firewall. To use a fixed port, set this
# this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
# For more information, see rpc.statd(8) or
http://wiki.debian.org/?SecuringNFS
STATDOPTS=
# Do you want to start the idmapd daemon? It is only needed for NFSv4.
NEED_IDMAPD=
# Do you want to start the gssd daemon? It is required for Kerberos mounts.
NEED_GSSD=
- on client, gssd idmapd statd are started
- Kerberos 5, both server and client have machine keys for
host/machine@REALM and nfs/machine@REALM with only
des-cbc-crc:normal, both server and client have "allow_weak_crypto"
in /etc/krb5.conf, user and group IDs are exported with NIS, clocks
difference is within allowed skew, user credentials are forwarded
over ssh logins; kerberos logs to /var/log/auth.log on server look
o.k.
--- End Message ---
--- Begin Message ---
Hi
[This reply and bug closer is sent for doing BTS maintenance for
src:nfs-utils bugs]
This bug was reported against a very old nfs-utils version without much
followups/triaging itself.
If you can reproduce it with the current version in unstable/testing or
stable at least, please reopen the bug,
https://www.debian.org/Bugs/server-control for details.
Regards,
Salvatore
--- End Message ---
