On a Koji hub, /mnt/koji needs to be exported to the builders. In a kerberized environment using rpc.svcgssd on the NFSv4.1 server, this could be accomplished by the following in /etc/exports, where /export/koji is mode 0755:

/export 10.10.10.0/24(fsid=0,crossmnt,sec=krb5p:krb5i)
/export/koji 10.10.10.0/24(ro,all_squash,sec=krb5p:krb5i)

The all_squash option is in place to allow the kojibuilder user who runs mock on the koji-builder client to access /mnt/koji without the need for kojibuilder credentials. The client has /mnt/koji created from /etc/fstab as:

kojihub.example.com:/koji /mnt/koji nfs ro,minorversion=1,sec=krb5i,x-systemd.automount 0 0

The issue comes in after switching from rpc.svcgssd on the NFSv4.1 server to gssproxy:

The koji-builder clients are no longer able to access /mnt/koji and rpc.gssd fails with the following errors:

ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - Can't find client principal kojibuilder@...
Error doing scandir on directory '/run/user/<uidnum_of_kojibuilder_user>': No such file or directory

NOTE: The only change is switching from rpc.svcgssd to gssproxy on the NFSv4.1 server.

However, creating and exporting a keytab for the kojibuilder user and enabling gssproxy on the koji-builder client allows access again, though not via the nobody user, as expected.

I'm not an expert on the implications of using all_squash on a sec=krb5 mount, and I actually think rpc.svcgssd might be "wrong" by allowing access to an export for a user without any creds (even if that user is supposed to be mapped to nobody via all_squash).