I'd look at the permissions of the ASPNET user on the machine you're trying to create the file on. Specifically, see if the ASPNET user can create files at the directory you're trying to create them.

ASPNET has read/write/modify. Apparently there is a "doublehop" issue where the creds passed from the webpage to the IIS webserver (the Workflow server) don't get re-passed to the remote server. Instead, the Network Service account takes over. Unfortunately, we don't have kerberos enabled so the only workaround is to modify the web.config file and set the IIS Directory Security for that project to Basic Authentication, which I don't like because it send clear text password to the IIS server.

I have run other components that have the same issue. Unless the process you are trying to initiate is on the Workflow Server and only affects the Workflow server, you have to work around IIS limitations. For my immediate purposes, I may use Task Server to accomplish my processes. This is not ideal, but it is what it is.

However I do plan to test Workflow using IIS7.

At this point I am using a Domain account with rights to do what I need on the remote machines as the identity in a custom AppPool that I assigned to my project and it is working. Come to find out that we do have Kerberos and it is configured correctly but that didnt help the issue. I'll post if I find a better way.