I am not an selinux maintainer, but this appears to be a labeling issue similar to the one in Bug 2299047.

A possible solution is use "chcon" to relabel /home/MyUsername/MyFolder:

$ chcon -t svirt_image_t /home/MyUsername/MyFolder

Verify the relabeling with the "-Z" option to "ls":

$ ls -lFndZ /home/MyUsername/MyFolder

The svirt_image_t label should allow the following accesses:

$ sesearch -A -s virtqemud_t -t svirt_image_t -c dir -dt
allow virtqemud_t svirt_image_t:dir { add_name create link remove_name rename reparent rmdir unlink watch watch_reads };

$ sesearch -A -s virtqemud_t -t svirt_image_t -c file -dt
allow virtqemud_t svirt_image_t:file { append create link rename setattr unlink watch watch_reads write };

Documentation:

$ whatis chcon ls sesearch customizable_types
chcon (1)            - change file security context
ls (1)               - list directory contents
sesearch (1)         - SELinux policy query tool
customizable_types (5) - The SELinux customizable types configuration file

$ fgrep virt /etc/selinux/targeted/contexts/customizable_types
svirt_image_t
svirt_home_t
svirt_sandbox_file_t
virt_content_t

Here is a better way. These are VM-related directories under /home that selinux supports by default:

$ sudo semanage fcontext -l | fgrep svirt_home_t
/home/[^/]+/\.cache/libvirt/qemu(/.*)?             all files          unconfined_u:object_r:svirt_home_t:s0 
/home/[^/]+/\.config/libvirt/qemu(/.*)?            all files          unconfined_u:object_r:svirt_home_t:s0 
/home/[^/]+/\.libvirt/qemu(/.*)?                   all files          unconfined_u:object_r:svirt_home_t:s0 
/home/[^/]+/\.local/share/gnome-boxes/images(/.*)? all files          unconfined_u:object_r:svirt_home_t:s0 
/home/[^/]+/\.local/share/libvirt/boot(/.*)?       all files          unconfined_u:object_r:svirt_home_t:s0 
/home/[^/]+/\.local/share/libvirt/images(/.*)?     all files          unconfined_u:object_r:svirt_home_t:s0 

So try creating one of those directories and moving your shared folder into it. Selinux will automatically generate the correct labels:

$ mkdir -p .libvirt/qemu

$ ls -lFndZ .libvirt .libvirt/qemu
drwxr-xr-x. 1 1000 1000 unconfined_u:object_r:virt_home_t:s0  8 Dec 31 22:15 .libvirt/
drwxr-xr-x. 1 1000 1000 unconfined_u:object_r:svirt_home_t:s0 0 Dec 31 22:15 .libvirt/qemu/

And these are the allowed accesses:

$ sesearch -A -s virt_domain -t svirt_home_t -c dir -dt
allow virt_domain svirt_home_t:dir { add_name create ioctl link lock read remove_name rename reparent rmdir setattr unlink watch watch_reads write };

$ sesearch -A -s virt_domain -t svirt_home_t -c file -dt
allow virt_domain svirt_home_t:file { append create getattr ioctl link lock open read rename setattr unlink watch watch_reads write };

Documentation:

$ whatis semanage-fcontext
semanage-fcontext (8) - SELinux Policy Management file context tool

See, also:

$ whatis restorecon
restorecon (8)       - restore file(s) default SELinux security contexts.

Thanks, Steve, for these workarounds. Adding the 'svirt_image_t' label to the shared directory has solved my AVC denials.

Sharing a directory in a special location does not quite match my usecase, though. I use the VM for my tax software (which is of course Windows only) and the shared directory is where I save the files from that program (the project file for the current year as well as the PDF summary that is created when I submit everything). I want these to be archived in my Documents directory, which is synced among my machines and automatically backed up to B2, and not having to remember that they are in a special directory because I had to use a VM on a SELinux system to work on them.

I am going to leave it open so a maintainer can actively decide if this is intended behavior or not. And if it is intended, if there is some additional documentation needed instead of having a kind stranger point out workarounds in a bug report.

(In reply to Lars Geiger from comment #3)
> Thanks, Steve, for these workarounds. Adding the 'svirt_image_t' label to the shared directory has solved my AVC denials.

Thanks for confirming that.

> Sharing a directory in a special location does not quite match my usecase, though.
...

Personally, I never use those special locations for my VMs, so I manually set the selinux labels using "chcon". The "semanage fcontext -l" output (Comment 2) is useful for determining what those selinux labels should be.

However, you can mount a filesystem or a directory in two places using the "bind" option to "mount".

This example does not involve VMs, but it does show a working configuration from /etc/fstab:

/dev/mapper/vg_VG1-lv_xfr1 /mnt/xfr1                     ext4    nofail            0 2
/mnt/xfr1 /home/USER1/xfr1                               ext4    nofail,bind       0 0

The "nofail" option is used to prevent a boot-stall if the filesystem cannot be mounted.

Documentation:

$ whatis -s 8,5 mount fstab
mount (8)            - mount a filesystem
fstab (5)            - static information about the filesystems

(In reply to Lars Geiger from comment #3)
> And if it is intended, if there is some additional documentation needed instead of having a kind stranger point out workarounds in a bug report.

That's a good point. This web page doesn't even mention selinux:

Sharing files with Virtiofs
https://libvirt.org/kbase/virtiofs.html

This might have some useful suggestions:

QEMU virtio-fs shared file system daemon
https://virtio-fs.gitlab.io/qemu/tools/virtiofsd.html

This message is a reminder that Fedora Linux 41 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '41'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 41 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Still occurs in Fedora 43.