What were you trying to do that didn't work?

In Cockpit's current RHEL 10 test VM refresh we noticed an NFS regression. Trying to create a libvirt NFS pool takes very long, then fails, and then makes the VM explode with a dozen setroubleshootd instances.

What is the impact of this issue to you?

Test regression (we can work around the setroubleshoot trouble)

Please provide the package NVR for which the bug is seen:

nfs-utils-2.7.1-1.el10.x86_64
libtirpc-1.3.5-0.el10.x86_64
selinux-policy-targeted-40.13.12-2.el10.noarch

How reproducible is this bug?:

Always

Steps to reproduce

setsebool -P virt_use_nfs 1
mkdir -p /var/lib/pool /var/lib/exports
echo '/var/lib/exports 127.0.0.1/24(rw,sync,no_root_squash,no_subtree_check,fsid=0)'  >> /etc/exports
systemctl restart nfs-server
virsh pool-define-as nfs-pool --type netfs --target /var/lib/pool --source-host 127.0.0.1 --source-path /var/lib/exports
virsh pool-start nfs-pool

Expected results

Succeeds.

Actual results

Starting the pool fails:

error: Failed to start pool nfs-pool
error: internal error: Child process (/usr/bin/mount -o nodev,nosuid,noexec 127.0.0.1:/var/lib/exports /var/lib/pool) unexpected exit status 32: mount.nfs: access denied by server while mounting 127.0.0.1:/var/lib/exports

It also triggers an avalanche of SELinux denials and errors, but most/all of them are "permissive=1" and actually happen on Fedora 40 as well, so I think that's just a red herring (albeit an annoying one, as setroubleshootd just goes crazy).

It still fails with setenforce 0, so I don't think it's acually an SELinux problem.