If I copy the same file from CIFS, it opens fine.
I inspected all the file permissions and md5 and the files (copied from cifs; copied from nfsv4) are exactly the same.
But the one copied from nfsv4 will not open.
The only thing I see, error wise, is some fs-cache messages at the text console.
No fscache, fsc or cachefiles are in use.

The home folder itself is stored on a local ext4 disk.
Rebooting the server does not fix the issue. User is still unable to access the files by double click on the desktop.
Happens with selinux enabled or disabled.
Same setup works fine on RHEL 7.7.

A small difference between the files can be seen by right click > properties > permissions. The file from NFSv4 has a "-" at "Allow executing file as program". 
But cleaning the check box does not fix the issue.

Also see sometimes a "Execution of command full_path_to_the_file_at_desktop", "command not found notification".

This is misfiled against gnome-desktop3. I'll assume that you copied the file in nautilus, and move the bug there.

The files on your server are probably marked as executable for some reason. NFS is aware of UNIX permissions, thus the copied files are also marked as executable. CIFS doesn't have enabled UNIX Extensions by default, thus the exectuable permissions are not copied. Consequenlty, the desktop-icons extensions tries to execute the file instead of opening: https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/issues/144, which is fixed by  https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/147. So changing component to gnome-shell-extensions as it would be probably nice to backport the mentioned fix, however, the root of the problem seems to be simply the wrong permissions...

gnome-shell-extension-desktop-icons-3.32.1-18.el8.noarch

Reproducer:
1. Login to gnome-classic, mount nfs4 storage
2. copy text file to ~/Desktop from the nfs storage via terminal
3. open nautilus, navigate to nfs4 share, copy a .png image to ~/Desktop folder

Result:
 Both files have desktop icons and can be opened in gedit/eog by clicking on their icons.

However after reading Comment 6, I tried the same reproducer but before copying files I marked them as executable:
 - the .png file was opened in eog as expected
 - nothing happens after clicking on .txt file

I understand that based on permissions the extension tries to execute the file but I just want to be sure before I verify this,
so is this expected ?

(In reply to Martin Krajnak from comment #8)
> gnome-shell-extension-desktop-icons-3.32.1-18.el8.noarch
> 
> However after reading Comment 6, I tried the same reproducer but before
> copying files I marked them as executable:
>  - the .png file was opened in eog as expected
>  - nothing happens after clicking on .txt file
> 
> I understand that based on permissions the extension tries to execute the
> file

That was the case before the fix.

With the fix, the extension *also* checks whether the content type (based on the file extension) can be executable. That's why the image now opens as expected, but unfortunately text files *may* be executable (as documented in https://gitlab.gnome.org/GNOME/glib/-/blob/master/gio/gcontenttype.c#L648).

I could add another special-case to not execute executable files of type "text/plain", but that would mean that scripts without .sh suffix aren't executed anymore.

I suspect that that's a more common case than a wrongly set executable bit, so I'm a bit wary of diverging from upstream here.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: GNOME security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:4381