The test program 'fsmount.c' sent in [1], can be used along with the test script below to show a kernel bug when calling fsconfig(2) with any valid option for an nfs mounted filesystem. This problem is not related to the btrfs bug I reported in [1], however I suspect that once vanilla NFS options can be set, it may uncover the same issue as in [1]. [1] https://lore.kernel.org/selinux/c02674c970fa292610402aa866c4068772d9ad4e.camel@xxxxxxxxxxxxxx/T/#u Copy the statements below into nfs-test.sh and run. MOUNT=/home # must be a top-level mount TESTDIR=$MOUNT/MOUNT-FS-MULTI/selinux-testsuite systemctl start nfs-server exportfs -orw,no_root_squash,security_label localhost:$MOUNT mkdir -p /mnt/selinux-testsuite # mount works: #mount -t nfs -o "vers=4.2,rootcontext=system_u:object_r:unconfined_t:s0" localhost:$TESTDIR /mnt/selinux-testsuite # Both of these give: Failed fsconfig(2): Invalid argument (nfsvers=4.2 or vers=4.2 fail) ./fsmount nfs localhost.localdomain:$TESTDIR /mnt/selinux-testsuite "nfsvers=4.2" #./fsmount nfs localhost.localdomain:$TESTDIR /mnt/selinux-testsuite "nfsvers=4.2,rootcontext=system_u:object_r:unconfined_t:s0" umount /mnt/selinux-testsuite exportfs -u localhost:$MOUNT systemctl stop nfs-server
