Hi Jeff,
As you know, the correct solution is to provision a LUN with adequate space to receive your cloned copy using vmkfstools. Anything other than that, especially steps that involve the permanent deletion of your data is not the kind of advice I should provide here.
I understand that you are currently performing a copy of the large data drive to the NAS. However, what if permissions don't work. What if this device stays offline and violates an SLA for your organization. Once the vmdk is deleted there is no turning back. Only you can gage those affects. Perhaps you can escalate and get more storage for this purpose? If this server is truly unimportant and you don't have the required tools to recover (i.e. freespace) then you may consider communicating this in a big red email and let someone else (i.e. mgmt at your org) make that decision.
I would much rather see you remediate this in a more standard / supported fashion. Some other options are to use VMware Converter and bring the machine online in a different farm for example (if one exists with more space). Or simply present that NAS storage to one or more of your hosts as a datastore; then use this to house the large vmdk of the rescue clone operation. Once the VM is powered on and functional (allbeit at lower IO rates on NFS) then you could consider deleting the source vmdk. The main objective is to test the VM before deleting the orginal disk. When the VM is powered on and functional, then it's easy to tell what is safe to delete, as VMware won't let you delete a file that's in use.
By doing the NAS copy method you proposed, you are forced to delete the original vmdk at some point through your process before testing the success of your safety copy. Again, the lack of testing is for no technical reason, just lack of space. We can craft a 1000 great ways to get the data off the disk, and magically back into a vmdk, but nothing changes the fact that your plan involves deleting the only copy of this data before it has been verified as functional.
If you must do the NAS copy, I will reluctantly provide some useful robocopy switches that I have used for similar requirements in the past. If your current copy method accounts for all such options already then disregard.
Robocopy Tips:
When performing a copy of a live server, of course many files will be in use and cannot be copied. To workaround this what is often used is a tool such as robocopy, which is smart enough to only copy files that have changed (deltas). So a copy process can be started a few days in advance, then at the final cut-over time, stop all services that may be locking files then do one final delta copy.
By default robocopy retries each locked file 1 Million times (or something crazy like that) with a wait delay time of 30 seconds. Since many files will be in use during the initial copy, it is best to set a limit on the retries and set the wait down to 5 seconds for example. Also notable, the /sec option will include the security/permissions.