diff --git a/install.sh b/install.sh
index c4aef1b..7b9c74c 100755
--- a/install.sh
+++ b/install.sh
@@ -263,6 +263,8 @@ done
 for f in libexec_startup/*; do
     install_exec "$f"                                     "$DESTDIR$usr_exec_prefix/libexec/startup/$(basename "$f")"
 done
+install_data misc_etc_files/request-key.d/id_resolver.conf \
+                                                          "$DESTDIR$sysconfdir/request-key.d/id_resolver.conf"
 
 postinstall
 exit
diff --git a/misc_etc_files/request-key.d/id_resolver.conf b/misc_etc_files/request-key.d/id_resolver.conf
new file mode 100644
index 0000000..8179a6d
--- /dev/null
+++ b/misc_etc_files/request-key.d/id_resolver.conf
@@ -0,0 +1,22 @@
+# nfs clients of a kernel before 5.15.89.mx64.445 try to use the id_resolver
+# for sec=mariux mounts when uid or gid file attributes are transmitted to the
+# server (e.g. when chown or chgrp is done).
+#
+# The kernel nfs clients makes a user space upcall via /sbin/request-key for a
+# key of a type id_resolver and a key description like "user:130" or
+# "group:125".
+#
+# As keys of the type id_resolver are not configured in /etc/request-key.conf,
+# this will fail but /sbin/request-key logs "request-key: Cannot find command
+# to construct key..." to its stdout which ends up in the syslog.
+#
+# The nfs clients continues by sending the uid/gid value numerically to the nfs
+# server, which is what we want.
+#
+# In this file, we configure a (negative) request-key response for keys of the
+# type id_resolver to avoid logfile spam.
+#
+# Kernels since 5.15.89.mx64.445 don't need that, because the userspace upcall
+# is avoided for sec=mariux just the same as it is for sec=sys.
+
+create id_resolver * * /bin/keyctl negate %k 300 %S