Again, the problem is with opportunistic locking, or rather, its lack there of, with SMB1.0
This mostly manifests in issues with ensuring data integrity on writes, but also causes problems with caching on reads, with large files.
https://www.dataaccess.com/kbasepublic/files/ … ase_pdf_fmt.pdf
In a nut-shell, SMB 1.o does a very poor job of reading or writing files in a random-manner from a client. The technology was not intended to host very large files over the network (in the case of SMB1.0), and this results in broken reads, cache misses, generally very poor performance, and in the case of writes, data losses. The technology very much intends for the client to pull THE ENTIRE FILE, and CACHE IT LOCALLY, then upload THE ENTIRE FILE when you are done with modifying it, in the case of SMB1.0
This is not suitable for the purposes outlined with mounting the image across the network, as described. (It works acceptably well with SMB 2.0 and SMB 3.0-- such as when used to host disk images for hacked game consoles, or disk libraries across the LAN on modern versions of windows--, because of improvements in how the protocol works, but DOS's implementation of SMB is **NOT** SMB 2.0 or 3.0 !!!)
This is why the OP will be much better suited pulling the full .ISO into a ramdisk (to function as a local cache), then mounting it there, and then purging after they are done playing.
(NOTE-- the linked article discusses disabling oplocking for database files, and how to do this on NT and newer versions of windows. Note, that the SMB 1.0 implementation used by dos, and the CIFS implementation used by windows NT and newer, ARE NOT THE SAME PROTOCOL. The PDF is more geared toward the CIFS variant, while we are discussing the old, "ACTUALLY REAL SMB1.0" found in DOS clients.)
https://www.upguard.com/blog/cifs-vs-smb
Note that "Larger Files" support, is one of the selling points for the newer CIFS dialect used by win9x and pals. The DOS network suppliment does not speak CIFS. It speaks SMB1.0
Since this basically tabulates out to "You really should just pull the whole damn file and cache it locally" no matter which route you take, coupled with "The SMB1.0 stack is bloated and huge, and takes up gobs and gobs of conventional memory", you end up with the suggestion I and others hit on: Use a simple packet driver and a simple file transfer client to pull the files, then mount them-- or use one of the more modern remote-drive protocol service providers using such a simple packet driver arrangement.
Either one will give you a better experience.