I suspect the problem you are having is because micnativeloadex, like programs written using offload directives, runs code on the coprocessor as a special user, "micuser", not as you. You can, of course, log directly into the coprocessor and run the code as yourself. Another alternative is to create a micuser on the host, with the same user and group id numbers as it has on the coprocessor (400 for both user and group id), then make sure micuser has permission to access the files on the host. Perhaps, put the files into /home/micuser on the host so that they pop up in /mic/micuser on the coprocessor.

Well, unless you have some special hoops you need to jump through that specifically require using micnativeloadex, you should be able to replace that with some number of scp commands followed by an ssh to the card, to download your code and libraries and then launch your application on the coprocessor.  And using scp and ssh directly would let you use any user account enabled on the coprocessor rather than sticking with "micuser," which is baggage that comes along with using micnativeloadex. (See the MPSS_Boot_Config_Guide.pdf included with the latest MPSS release for details on setting up coprocessor user accounts.)

So you NFS-mount your disk partition on the coprocessor and read data over that pipe.  That doesn't change the decision whether to use micnativeloadex versus ssh and scp (the scps intended only for copying your a.out and support SOs to the coprocessor VFS).  Micnativeloadex does exactly this sort of copying of execution files (not data files) before doing the native launch on the coprocessor side.

Robert's comment made me think of something. If you nfs mount your data, and your home directories and the directories with your libraries, you should (with judicious use of path and library path variables) be able to very simply say:

ssh mic0 the_program_I_am_trying_to_run