FindFirstFile() and FindNextFile() are basic Windows APIs to check for presence of files or to enumerate them. Any Win32 API software dealing with files will use them somehow unless you want to directly go through the Win NT kernel interface functions in nt.dll, which Microsoft discourages to do. The List Folder node in your VI uses exactly these functions to enumerate the source directory. The Copy node may use the FindFirstFile() function to check for the presence of the file in the target path but shouldn't really need to call FindNextFile(). It could also call GetFileAttributes() instead to check for the presence of the file and that would very likely result in a similar SMB command stream. From a client respective FindFirstFile() is similar to GetFileAttributes() but returns additional information about the file entry and not just the basic file attributes and indication if the file or directory exists. I could imagine that on the SMB level it also uses the same or a similar request.
The NO_MORE_FILES error seems to come from the server so it would be interesting to look at the request just before that to see what path was requested info for.
It may be related to the other issue but not necessarily. The issue in the thread you mention is that if special files or directories are located in a directory, that alphabetically sorted appear before the . and .. entry, then the List Folder function will fail to filter out the . and .. directory entries as it assumes that they are always the first two entries returned by FindFirstFile() and FindNextFile(). That was apparenty not an issue for SMB1 volumes as the SMB1 driver sorted the file entries accordingly that the . and .. entries were always the first two, and is still not an issue for local file systems, but SMB2 seems to have abandoned the DOS compatibility sort order.
The List Folder node itself won't get stuck in an endless loop. The Recursive File List.vi convenience function however will, as it falsely will attempt to enumerate the two returned . and .. entries in LabVIEW versions prior to 2019.